Здравствуйте, rsdn_179b, Вы писали:

_>>Интересует собственно сабж — откуда берутся эти самые "ложные пробуждения" ?

Кстати, вот хороший кусочек из обсуждения на SO:

The pthread_cond_wait() function in Linux is implemented using the futex system call. Each blocking system call on Linux returns abruptly with EINTR when the process receives a signal. ... pthread_cond_wait() can't restart the waiting because it may miss a real wakeup in the little time it was outside the futex system call. This race condition can only be avoided by the caller checking for an invariant. A POSIX signal will therefore generate a spurious wakeup.

Summary: If a Linux process is signaled its waiting threads will each enjoy a nice, hot spurious wakeup.

коммент

This EINTR unblocking is true of all blocking system calls in Unix derived systems. This made the kernel lots simpler, but the application programmers bought the burden.

вопрос

I thought pthread_cond_wait() and friends could not return EINTR, but return zero if spuriously woken up? From: pubs.opengroup.org/onlinepubs/7908799/xsh/… "These functions will not return an error code of [EINTR]."

и ответ

That's right. The underlying futex() call returns EINTR, but that return value isn't bubbled up to the next level. The pthread caller must therefore check for an invariant. What they're saying is that when pthread_cond_wait() returns you must check your loop condition (invariant) again, because the wait might have been spuriously woken up. Receiving a signal during a system call is one possible cause, but it's not the only one.

http://stackoverflow.com/questions/1050592/do-spurious-wakeups-actually-happen

Имхо, вполне исчерпывающе: особенности реализации плюс некоторая кривизна интерфейса (что EINTR не возвращается, даже если он является причиной вылета из блокирующего ожидания).

You will always get what you always got
  If you always do  what you always did