TThread.Suspend is functional or not?

[PascalDragon]

A much better approach is to have the thread that is responsible for performing a specific task to notify the thread interested that the task has been completed.  When the thread responsible for performing the task is done with it and, after it sends the notification, it simply suspends itself.  No need for synch objects of any kind which keeps the app much simpler than when using synch objects.

But that's the important point: it ... suspends itself.

Please just do not spread discussion, there is many reasons why Suspend/Resume is desired, not just because of wish to generally debug code or preliminary attempt to check data or stop thread.

But then you need to implement your own suspension mechanism (like in 440bx' example that the thread suspends itself) cause only then you can be sure that the thread does not get suspended right in the middle of a critical section or something similar that would in the end lead to a deadlock. Thus the general Suspend is deprecated. And that's also why it's only deprecated and not removed, because there might be legitimate and safe situations where you might want to use it.

[backprop]

Don't tell us, tell microsoft

I have nothing related with M$ nor Windows for approx. 2 decades. And I do not really care. What they doing with customers with Windows 11, their future is quite certain. Windows was always been one big virus and malware and now that is defacto open and confirmed, spying customers and requiring to buy new hardware even current is perfectly fine, due their unlawful activity require more...

Linux is perfectly fine to do anything now and they still do not doing silly things as M$. Linux is still OS which do exactly as user asks from it... And M$ certainly can't dictate anything anymore...

But I do not want to spread discussion on that, I do not really care what M$ forcing I do not use it anymore.

[Martin_fr]

I did in the past and making some emulators for old hardware where temporary suspending action is useful

First of all, if I read this thread correct (maybe not?) then it always only worked on some OS? And on those you can still call the OS API directly?

My first question would have been, why? A thread needs to be suspended if it has nothing to do, that the thread knows itself, so it can "pause" itself when appropriate. Even if it has to tell another thread, that it did finish the work, it would not have any need to keep going until that other thread would suspend it.

But I guess, you try to pause a busy thread? And for some reason prefer not to need to check regularly for some flag?

The problem is, that a lot of code will enter critical section or other thread-sync/lock constructs. Even if you don't think it will. E.g. memory managers may (I don't know which ones will, or wont, but unless you have proof the one you use doesn't, assume it does.

Then your problem is, if your thread used anything that could alloc/free mem, and you suspend it in the wrong moment, all your other threads will start locking if they too use alloc/free.

Yes, apparently you done suspend for a long time, and it hasn't happen to you yet. That is the nature of race conditions. I don't know if you distribute the software in question. But if it hangs on 5 to 10% of your users, say once every 6 month, and they can't reproduce it, and aren't sure it wasn't something else with their system => they wont even report it.

Well,... just my 2 cents.

[PascalDragon]

Linux is perfectly fine to do anything now and they still do not doing silly things as M$. Linux is still OS which do exactly as user asks from it... And M$ certainly can't dictate anything anymore...

But on non-Windows you need to implement your own suspension mechanism anyway, cause POSIX threads don't support that functionality (in general). Thus to support it in a cross-platform way it's best to do your own mechanism based on event mechanisms.

[440bx]

But that's the important point: it ... suspends itself.

Most definitely.  You're right about that.

I believe you understand the point I'm making that suspend/resume thread are not only perfectly usable but very convenient when used properly by an app.  MS is right when they imply that resume/suspend thread should not be used for synchronization since they really are not suited for that purpose.

As you pointed out, if poor app design opens the door to the possibility of suspending a thread when it holds a resource, that's not a problem with suspending the thread, it's a design problem, not an API problem.

The other point I want/wanted to make is that suspend/resume thread can be extremely useful in creating responsive and well modularized programs.  IOW, there is no genuine reason to avoid their use.  Of course, there is good reason not to misuse them.

[backprop]

But on non-Windows you need to implement your own suspension mechanism anyway, cause POSIX threads don't support that functionality (in general). Thus to support it in a cross-platform way it's best to do your own mechanism based on event mechanisms.

Done in the past and will be done in the future the same way.

[marcov]

Linux is perfectly fine to do anything now and they still do not doing silly things as M$. Linux is still OS which do exactly as user asks from it... And M$ certainly can't dictate anything anymore...

So how do you ask Linux to suspend an uncooperative thread?

As the comment in unix/cthreads says.....

{  pthread_kill(SIGSTOP) cannot be used, because posix-compliant
       implementations then freeze the entire process instead of only
       the target thread. Suspending a particular thread is not
       supported by posix nor by most *nix implementations, presumably
       because of concerns mentioned in E.4 at
       http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#E and in
       http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
    }
//      result := pthread_kill(threadHandle,SIGSTOP);
      result:=dword(-1);