Subj : Re: Real cause of spurious wakeups To : comp.programming.threads From : Ben Hutchings Date : Fri Apr 01 2005 04:23 pm Vladimir Prus wrote: > Joe Seigh wrote: > >>> 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. > > So, > - wait on futex returns EINTR on signal > - cond_wait implementation immediately returns on EINTR > > Well, that's a reason. However, there are still two questions: > > - why wait of futex returns on signals? The futex() caller may want to respond to the signal. Also signal handling can involve calling user-space code, which may make it hard to preserve the in-kernel context of the futex() call. > - as you indicate, cond_wait returns on EINTR just because it's allowed to. > Would be possible to waits on futex again in that case. No, because a notification might be missed. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. .