Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>

Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Peter Dimov (lists_at_[hidden])
Date: 2014-05-05 13:56:31

Niall Douglas wrote:

> Firstly, permits are a notification object, not a serialisation object. If 
> you have some predicate P whose state you are changing you must protect it 
> with a mutex, just like any other code. This is why permit.wait() takes a 
> locked mutex.

But you do have a wait() function that takes nothing?

> Reworking your example thusly:
>
> Initially P is 0 and p_mutex is unlocked.
>
> Tc1, Tc2 lock p_mutex and call wait.
>
> Tp1 locks p_mutex, sets P=1 and calls notify_one. Upon Tp1 releasing the 
> mutex, Tc1 is unblocked with mutex locked, returns from wait, but is 
> immediately suspended by the scheduler for unfathomable scheduling 
> reasons, like its code causing a page fault.
>
> Tp2 tries to set P=1, but gets blocked on the mutex being held by Tc1. 
> When Tc1 is resumed and eventually unlocks the mutex, everything else 
> proceeds as normal.

This assumes that notify_one is called before releasing the mutex. Condition 
variables allow notify_one outside the mutex. Is this use not supported by 
permits?