Jump to content
Clément

TThread Resume Suspend deprecated (Not synchronization)

Recommended Posts

I wrote a old listener derived from TThread, and I'm using Suspend/Resume when +100 connections are made.
The code is simple :

  if (FThreadCount > _MAX_THREADS) and Assigned(FListener) then
    FListener.Suspend;
  if (FThreadCount < _MAX_THREADS) and Assigned(FListener) then
    FListener.Resume;

The compiler is complaining both methods are deprecated. So... should I ignore the warning (W1000) or use a different approach to limit the connections? What would that be?

 

Thanks

 

Share this post


Link to post

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Classes.TThread.Suspend

 

Warning: Suspend is deprecated.

Pauses a running thread. Suspend was intended to be used by debuggers and is deprecated in RAD Studio XE, in the year 2010.

Call Suspend to temporarily halt the execution of the thread. To resume execution after a call to Suspend, call Resume. Calls to Suspend can be nested; Resume must be called the same number of times Suspend was called before the thread resumes execution.

Warning: The Resume and Suspend methods should only be used for debugging purposes. Suspending a thread using Suspend can lead to deadlocks and undefined behavior within your application. Proper thread synchronization techniques should be based on TEvent and TMutex.

 

Share this post


Link to post

I'm looking for something like this...

 

https://docs.microsoft.com/en-us/windows/win32/procthread/suspending-thread-execution

 

"A thread can suspend and resume the execution of another thread. While a thread is suspended, it is not scheduled for time on the processor.

If a thread is created in a suspended state (with the CREATE_SUSPENDED flag), it does not begin to execute until another thread calls the ResumeThread function with a handle to the suspended thread."

Share this post


Link to post
51 minutes ago, Clément said:

I assume you are not building a debugger because it says:

 

Quote

The SuspendThread function is not intended to be used for thread synchronization because it does not control the point in the code at which the thread's execution is suspended. This function is primarily designed for use by debuggers.

 

Share this post


Link to post
2 hours ago, Anders Melander said:

I vote for this approach.  Limiting the listener to run only when the number of connections is below a max threshold is exactly the kind of situation that semaphores are intended for.  See Semaphore Objects for details.

Share this post


Link to post
2 hours ago, Clément said:

I'm looking for something like this...

 

https://docs.microsoft.com/en-us/windows/win32/procthread/suspending-thread-execution

 

"A thread can suspend and resume the execution of another thread. While a thread is suspended, it is not scheduled for time on the processor.

If a thread is created in a suspended state (with the CREATE_SUSPENDED flag), it does not begin to execute until another thread calls the ResumeThread function with a handle to the suspended thread."

 

There is nothing wrong with creating a suspended thread and then activating it later.  That's a little different than calling Suspend on an active thread which needs much more care.

 

Share this post


Link to post

Oh. Now See!
I'll study the Semaphore implementation

Share this post


Link to post
27 minutes ago, Darian Miller said:

That's a little different than calling Suspend on an active thread which needs much more care.

I don't think any amount of care can solve the issues there

  • Like 1

Share this post


Link to post
3 hours ago, Darian Miller said:

There is nothing wrong with creating a suspended thread and then activating it later.

Not sure what the situation is now (probably worse), but in the past the delphi debugger did not cope with debugging threads that were created suspended (the debugger/ide would hang when it hit the breakpoint) - so I prefer to create the thread normally and then block on an event or semaphore. Suspended/Resume was really just a misunderstanding of the api's on borland's part - which they corrected by deprecating the methods - they probably could have removed them by now, they have been deprecated for a while now. 

Share this post


Link to post

Suspended creation is Windows feature that they reflected 1:1 to class API but other OS's do not provide it so they had to imitate it via mutexes.

Share this post


Link to post
On 3/16/2022 at 7:56 PM, David Heffernan said:

I don't think any amount of care can solve the issues there

Just set a flag and call suspend from inside the thread it self. That will make sure that the thread code is not left in an unstable state it should have the same effect as using a locked mutex from the thread.

 

Resuming though will have to be done from a 3rd party ee the main thread or some thread manager perhaps. 

In any case, imagination is our limit.

Share this post


Link to post
15 minutes ago, taz said:

Just set a flag and call suspend from inside the thread it self. That will make sure that the thread code is not left in an unstable state it should have the same effect as using a locked mutex from the thread.

 

Resuming though will have to be done from a 3rd party ee the main thread or some thread manager perhaps.

This is better handled using a waitable mutex or other synchronization object.  The thread can wait on the object when it has nothing else to do, and another thread can signal the object to wake up the waiting thread.

  • Like 1

Share this post


Link to post
27 minutes ago, Remy Lebeau said:

The thread can wait on the object when it has nothing else to do, and another thread can signal the object to wake up the waiting thread.

This ^ is also a LOT faster than TThread.Resume

Share this post


Link to post

 

2 hours ago, Remy Lebeau said:

This is better handled using a waitable mutex or other synchronization object.  The thread can wait on the object when it has nothing else to do, and another thread can signal the object to wake up the waiting thread.

Agreed! it is always better to use existing well tested code instead of writing your own. I just added a safe use of the method to complete the picture.

2 hours ago, Vincent Parrett said:

This ^ is also a LOT faster than TThread.Resume

Good to know, I had no idea.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×