Subj : Re: Real cause of spurious wakeups To : comp.programming.threads From : Joe Seigh Date : Thu Mar 31 2005 08:53 pm On Thu, 31 Mar 2005 21:31:36 GMT, David Hopwood wrote: > Joe Seigh wrote: >> >> 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. The examples were probably some of the current implementations. I don't think anyone wanted to admit on record that their implementation would suck unless spurious wakeups were allowed. I think people were smiling a lot when they spoke that particular statement. A possible implementation might be the syscall not keeping enough state information to make it restartable after an EINTR. This is not the case for Linux which has enough information in the condvar and in the futex to make futex syscalls restartable on EINTR if they wanted to. The implementation I did is here http://atomic-ptr-plus.sourceforge.net/ though I doubt it's what they had in mind when they did the Posix spec. IIRC, it runs about 10% faster than the NPTL implementation, 3X faster if you "fix" condvar signals to not preempt. -- Joe Seigh .