Subj : Re: Real cause of spurious wakeups
To   : comp.programming.threads
From : Vladimir Prus
Date : Fri Apr 01 2005 11:55 am

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?
- 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. And would not that
  have no great effect on performance?

So, it looks I still haven't seen an example where avoiding spurious wakeups
will cause great performance loss of all condvar operations. And I'm still
interested to know ;-)

- Volodya

.