Alexander Bernauer wrote:

I wasn't aware of the fact that it is not required to have the mutex acquired when calling notify_*.

I believe it is preferred to not have the lock held because you can then have fewer context switches: if you notify with the lock held the waiting thread may be scheduled but it will immediately block trying to re-acquire the mutex, and the first thread will be scheduled again to release it. I haven't measured the effect this though. Is anyone aware of a correctness reason for not notifying with the lock held?

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.

Yes, i.e. lock mutex change state unlock mutex notify condition

So, I can see no additional penalty when encapsulating spurious wakeups.

You have the penalty of actually doing the spuriousness check and storing the extra state, as you described in your first post.

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.

Can you give an example? If your condition is very slow to evaluate and spurious wakeups are common then you may save time by eliminating the possibility of spuriousness before evaluating the condition. But my experience is that spurious wakeups are rare in practice. (The exception might be if your application makes a lot of use of signals, e.g. async IO or timers.)

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?

Well, it makes things slower for users whose conditions are simple or who have infrequent spurious wakeups.

Not to mention the fact that spurious wakeups are a very hard to detect bug in case one forgets to loop

Every instance of waiting on a condition should always be in a loop, or use the predicate version of wait.

or - even worse - there is a bug in the loop condition.

Regards, Phil.

On Thursday 05 February 2009 15:25:50 Phil Endecott wrote:

if you notify with the lock held the waiting thread may be scheduled but it will immediately block trying to re-acquire the mutex, and the first thread will be scheduled again to release it.

I checked the posix documentation and indeed it is not guaranteed that the above does not happen. I didn't expect that.

I haven't measured the effect this though.

Maybe some implementations are smart enough to avoid this scenario. At least I hope so.

Can you give an example?

In my case, I have two event queues. One for immediate events and one for delayed ones, i.e. something like std::queue<Event*> imQ; std::priority_queue<std::pair<system_time, Event*> > delQ; Both queues are encapsulated by a "meta"-queue class providing void push(Event*, time_duration delay=not_a_date_time) and Event* pop() Besides normal queue semantics the meta queue has the additional constraint that a delayed event may not be returned by pop() before its delivery time has been reached. Without spurious wakeups, we would have ---8<--- void push(Event* event, time_duration delay=not_a_date_time) { lock l(mutex); if (delay == not_a_date_time) { imQ.push(event); } else { delQ.push(std::make_pair(get_system_time() + delay, event)); } condition.notify(); } --->8--- and ---8<--- Event* pop() { lock l(mutex); while(1) { if (not imQ.emtpy()) { Event* event = imQ.top(); imQ.pop(); return event; } else { if (not delQ.empty()) { const system_time now = get_system_time(); if (delQ.top().first < now) { Event* event = delQ.top().second; delQ.pop(); return event; } else { condition.timed_wait(l, delQ.top().first); // (1) } } else { condition.wait(l); // (2) } } } } --->8--- While writing those lines I realized that the above code is correct even if there are spurious wakeups. My point was that (1) becomes ---8<--- while (imQ.empty() and get_system_time() < delQ.top().first and condition.timed_wait(l, delQ.top().first)); --->8--- and (2) becomes ---8<--- while(imQ.empty() and delQ.empty()) { condition.wait(); } --->8--- but this is not necessary. Maybe the above is a general pattern to avoid complicated loop conditions for spurious wakeups. If this is true, besides convenience, I have no argument left for encapsulating spurious wakeups. Thank you regards Alexander

Hi On Thursday 05 February 2009 20:26:32 vicente.botet wrote:

could you explain how your design helps to debug a bug in the loop condition?

In my design the loop against spurious wakeups is implemented once in the library. This can be reviewed and tested until its correct. In the boost design everybody has to implement its own loops. So my design does not help debugging. Instead it helps avoiding a whole class of hard to find bugs. regards Alex