Subj : Re: Windows Suspend/ResumeThread API equivalent for Linux or POSIX? To : comp.programming.threads From : David Schwartz Date : Wed May 11 2005 05:08 pm "Oliver S." wrote in message news:42828d3a@news-fe-01... >> Usually when people ask this question, they are barking up the >> wrong tree. Why do you think you need to suspend a thread? > Imagine you have an application which performes a computation-time > -intensely task in the background with a worker-thread (f.e. a rende- > ring-application). And this app would provide a pause-button to sus- > pend this calculations to free computing-power for a while. > Without an API similar to SuspendThread / ResumeThread you would have > to poll a volatile flag which is shared between the worker-threads and > the supervising thread. That takes performance (esspecially when mul- > tiple worker-threads share this flag on a SMP-system and need to MESI > -broadcast for a newer version of the cache-line containing that flag > to all CPUs) and when you need a fine granularity of the poll-inter- > val, you're likely to insert that polling-code in a lot of functions > which aren't related to this threading-issue. Umm, no, it would stay shared until it was modified. > Don't you think an API > like SuspendThread / ResumeThread is much smarter in that case ? No, I don't. In fact, it's a grossly ugly premature optimization. And if you suspend the thread while it holds the 'malloc' mutex, you're screwed. > And > as suspending an resuming a thread can be considered as a longer in- > terval of suspension through preemption, such an API could be provi- > ded 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. DS .