1. links
1.1 succinct answers
1.1.1 DECthreads guide:
http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-Q2DPC-...
pthread_cond_wait
"...
This routine might (with low probability) return when the condition
variable has not been signaled or broadcasted. When this occurs, the
mutex is reacquired before the routine returns. To handle this type of
situation, enclose each call to this routine in a loop that checks the
predicate. The loop provides documentation of your intent and protects
against these spurious wakeups, while also allowing correct behavior
even if another thread consumes the desired state before the awakened
thread runs.
..."

1.1.2 Multithreaded Programming :: Improving Performance through
Threads (pthreads Tutorial):
http://vergil.chemistry.gatech.edu/resources/programming/threads.html
"...
When waiting on condition variables, the wait should be inside a loop,
not in a simple if statement because of spurious wakeups. You are not
guaranteed that if a thread wakes up, it is the result of a signal or
broadcastcall.
[...]
Just because a thread has been woken does not mean it was due to a
pthread_cond_signal() or pthread_cond_broadcast() call.
..."

1.2 detailed answers with valuable background informations
1.2.1 Most Frequently Asked Questions
Q94: Spurious wakeups, absolute time, and pthread_cond_timedwait()
http://lambdacs.com/cpt/MFAQ.html#Q94

1.2.2 discussion "pthread_cond_wait waking up spuriously?"
http://groups.google.de/groups?threadm=slrn9euq45.hu.kaz%40cafe.net

1.2.3 discussion "What excatly is a spurious wakeup? (Was: discussion
on barriers)"
http://groups.google.de/groups?threadm=slrn9djb6l.ho.kaz%40cafe.net

1.2.4 discussion "pthread_cond_wait is unfair (POSIX threads)"
http://groups.google.de/groups?threadm=31B80BB0.59E2%40zko.dec.com

1.3 wording by the standard
The Open Group Base Specifications Issue 6, IEEE Std 1003.1:
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cond_...
"...
Spurious wakeups from the pthread_cond_timedwait() or
pthread_cond_wait() functions may occur. Since the return from
pthread_cond_timedwait() or pthread_cond_wait() does not imply
anything about the value of this predicate, the predicate should be
re-evaluated upon such return.
[...]
If a signal is delivered to a thread waiting for a condition variable,
upon return from the signal handler the thread resumes waiting for the
condition variable as if it was not interrupted, or it shall return
zero due to spurious wakeup.
..."

http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_...
"...
An added benefit of allowing spurious wakeups is that applications are
forced to code a predicate-testing-loop around the condition wait.
This also makes the application tolerate superfluous condition
broadcasts or signals on the same condition variable that may be coded
in some other part of the application. The resulting applications are
thus more robust.
..."

1.4 a manual page from the HP-UX documentation
http://www.calpoly.edu/cgi-bin/man-cgi?pthread_cond_timedwait+3
"...
A spurious wakeup occurs when a thread returns from a condition wait
when it should really continue waiting. A normal signal being
delivered to a thread may cause a spurious wakeup during a condition
wait. Since the return values from pthread_cond_wait() and
pthread_cond_timedwait() do not imply anything about the value of the
predicate, the predicate should be re-evaluated.
..."

2. development
2.1 I am interested in the special case when spurious wakeups must not
happen.
Does this case exist?

2.2 The pthreads interface does not officially provide this service.
Does any implementation offer a specific attribute to switch
"wake-only-once" semantics on?

2.3 Is the approach that is described in the discussion "An easier to
use Condition Variable API" the only one that tried to encapsulate the
predicate handling into a library?
Do you know more libraries with a similar design that offer a
"ConditionObject" implementation?
http://groups.google.de/groups?threadm=353C2FA9.67C212C7%40erdas.com

2.4 Did anybody try to connect the condition with a "signal handler"
or other callback function?
How do you think about an interpretation or approach that the signal
call safely notifies a receiver/consumer that the predicate became
true?