Hi all, thanks for your replies. I wasn't aware of the fact that it is not required to have the mutex acquired when calling notify_*. As you stated right, a different thread API, which encapsulates spurious wakeups, would demand the mutex to be aquired for call to notify_*. AFAICS, in order to trigger the notification one has to acquire the lock anyway, because the waiting thread loops around some value of a state, which one has to alter concurrently. So, I can see no additional penalty when encapsulating spurious wakeups. Furthermore, afaics, the sketched implementation of such an API is safe, isn't it? Does anybody know an example of a corner case which doesn't work? I am aware of the wait functions, which accept a predicate and do the loop for you. My point is, that expressing the loop condition is not always trivial. Therefore in those cases - at least up to my experience - normaly new flags or counters are introduced, which signal "Yes, it was really intended that you woke up". This is cumbersome. On the other hand those flags/counters are a safe way to solve the spurious wakeup problem in general. So why not having the library doing the job? Not to mention the fact that spurious wakeups are a very hard to detect bug in case one forgets to loop or - even worse - there is a bug in the loop condition. regards Alexander