TThread Resume Suspend deprecated (Not synchronization)

[Clément 148]

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

 

[Lajos Juhász 293]

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.

 

[Anders Melander 1784]

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.SyncObjs.TSemaphore

https://en.wikipedia.org/wiki/Semaphore_(programming)

[Clément 148]

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."

[qubits 20]

Using TEvent to pause thread execution.

 

Seems to work ok.

 

maybe there's something else i'm missing though, sorry..

[Stefan Glienke 2002]

51 minutes ago, Clément said:

I'm looking for something like this...

 

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

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.

 

[Remy Lebeau 1396]

2 hours ago, Anders Melander said:

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.SyncObjs.TSemaphore

https://en.wikipedia.org/wiki/Semaphore_(programming)

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.

[Darian Miller 361]

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.

 

[Clément 148]

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

[David Heffernan 2345]

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

[Vincent Parrett 750]

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. 

[Fr0sT.Brutal 900]

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.

[taz 0]

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.

[Remy Lebeau 1396]

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.

[Vincent Parrett 750]

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

[taz 0]

 

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.