Re: [boost] [threads] API Design Question

Subject: Re: [boost] [threads] API Design Question
From: Alexander Bernauer (alex_at_[hidden])
Date: 2009-02-05 06:56:12

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