Subj : Re: Real cause of spurious wakeups To : comp.programming.threads From : David Hopwood Date : Thu Mar 31 2005 09:31 pm Joe Seigh wrote: > On Thu, 31 Mar 2005 18:43:04 +0400, Vladimir Prus wrote: > >> can somebody explain the real reason why spurious wakeups are >> possible. That is, why call to pthread_cond_wait can return without >> pthread_cond_broadcast/pthread_cond_signal. I'm specifically talking >> about >> spurious wakeup caused by pthread implementation, not the one caused by >> loose predicate checking on the notifying side, or "stolen wakeup". I >> looked in archives for this group, and in the FAQ, but found only vague >> statements that on some SMP systems avoiding spurious wakeup is too hard. >> >> I understand that pthread_cond_wait need to be wrapped in a loop even if >> spurious wakeups did not exist. I'm asking just because the wakeups are >> mentioned everywhere, but I never seen a complete explanations. > > It allows flexibility in the implementation. A strict definition with > no spurious wakeups allowed could possibly require overly expensive > synchronization on some platforms. You get to make a tradeoff. The > occasional spurious wakeup for much better performance. You can > write your own condition variable that does not have spurious wakeups, > but it will not perform as well. You've given a generic answer that could apply to any instance of a relaxed specification whatsoever. How is this useful when the OP asked for a specific reason for this particular relaxation? > The Linux futex based condition variables return spurious interrupts on > signal interruptions. Not really for performance reasons, AFAICT. Just > because then can do it. > > I've written a faster futex based condition variable that wouldn't be > possible if spurious wakeups were not allowed. Then you're in a good position to give the OP a real answer to his question. I've only ever heard "it turns out to be hard" and "it might be costly" handwaving, without any analysis of the actual difficulty or cost. The c.p.threads FAQ has a brief discussion of this , and ends up concluding: >> You know, I wonder if the designers of pthreads used logic like this: >> users of condition variables have to check the condition on exit anyway, >> so we will not be placing any additional burden on them if we allow >> spurious wakeups; and since it is conceivable that allowing spurious >> wakeups could make an implementation faster, it can only help if we >> allow them. >> >> They may not have had any particular implementation in mind. > > You're actually not far off at all, except you didn't push it far enough. > > The intent was to force correct/robust code by requiring predicate loops. > This was driven by the provably correct academic contingent among the > "core threadies" in the working group, though I don't think anyone really > disagreed with the intent once they understood what it meant. > > We followed that intent with several levels of justification. The first > was that "religiously" using a loop protects the application against its > own imperfect coding practices. The second was that it wasn't difficult to > abstractly imagine machines and implementation code that could exploit > this requirement to improve the performance of average condition wait > operations through optimizing the synchronization mechanisms. But note that "it isn't difficult to abstractly imagine machines and implementation code that could exploit this requirement" isn't the same as actually describing a sketch of such an implementation. If it isn't difficult, I'd like to see one. -- David Hopwood .