Subj : Re: Windows Suspend/ResumeThread API equivalent for Linux or POSIX? To : comp.programming.threads From : David Schwartz Date : Wed May 11 2005 06:27 pm "Oliver S." wrote in message news:42829b2d@news-fe-01... >> No, I don't. In fact, it's a grossly ugly premature optimization. > That's your personal view, but _for_this_special_case_ this "opti- > mization" is ok under some circumstances. Do you really think that > polluting the code otherwise unrelated to threading-issues to check > a flag is less ugly ? Yes, by far. Because otherwise every single thing the thread does or could to must be made suspension-safe and deadlock free. >> And if you suspend the thread while it holds the 'malloc' mutex, >> you're screwed. > I've written a rendering-core of a PostScript-interpreter and this > rendering-core can be distributed among a number of processors in a > SMP-system. And the worker-threads of this core share a highly opti- > mized common memory-allocator for every device-oject. And if I sus- > pend all worker-threads attached to every device-object and using > the same memory-pool-object, this wouldn't cause any side-effects; > and there isn't any magic in taking care for this issue when wri- > ting code for worker-threads. Of course there could be cases where > you aren't able to design the worker-threads according to that rule > because you're forced to use a library that baffles that approach. And that's the problem. You're looking for a generic, portable mechanism that works with every pthreads implementation. This puts serious restrictions on what that implementation can do (for example, it can't asynchronously grab a thread and allocate memory unless it contains special code to make this suspension-safe). And why do you want this serious burden of code? To support one particular optimization that is usually a pessimization anyway. If you really want this, and really thing it's worth it, go ahead and code it. But you won't get help from anyone else unless you can convince them that the benfits outweigh the costs. >>> And as suspending an resuming a thread can be considered as a >>> longer interval of suspension through preemption, such an API >>> could be provided by an operating-system without a significant >>> cost in code-size or growth in complexity of the OS. > >> It is nothing like pre-emption, because with pre-emption, the >> thread will ultimately be rescheduled with no action from user >> code, so deadlock is not possible. > Of course this is possibe, but you misunderstood me. I simply wanted > to say that the OS-code for SuspendThread / ResumeThread use the same > code for suspending and resuming the thread which the scheduler uses. That would be a disaster, and a recipe for deadlock. If the suspending thread ever touched a resource that the suspended thread holds, there would be a deadlock. You would have to use a suspending routine that insured that such suspension-unsafe resources were not held (and what, retry the suspension later if they are?). Using the regular scheduler suspension mechanism would be suicidal. The normal scheduler suspension mechanism need not concern itself with deadlock because the suspended thread will resume without waiting for any resource another thread might hold. DS .