Re: [Boost-users] Re: Locking mechanisms other than scoped_lock

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2005-03-21 10:09:12

Vladimir Prus wrote:
> Ben Hutchings wrote:
> 
> 
>> > after which thread B will pick up the lock and write the data and
>>
>>>resets the boolean flag. After releasing the lock, threads A will
>>>immediately try to re-acquire the lock.
>>
>><snip>
>>
>>You might find that this works on your development machine, but it will
>>likely fail elsewhere.  There is no guarantee that releasing a mutex
>>that's blocking another thread is will wake that other thread.
> 
> 
> This is an interesting question. The situation is that thread B waits on a
> mutex and thread A first released mutex and then locks it again. POSIX says
> that:
> 
> 
>   If there are threads blocked on the mutex object referenced by mutex when
>   pthread_mutex_unlock() is called, resulting in the mutex becoming
>   available, the scheduling policy is used to determine which thread shall
>   acquire the mutex.
> 
> Which I interpret as saying that if B waits on the lock when A releases it,
> B will acquire the lock, as it's the only thread waiting on the lock. Am I
> wrong?
<snip>

I think you are right, but Boost.Threads isn't just a wrapper for 
pthreads.  Also, it strikes me now that there is also no guarantee that 
thread B is blocked by the time thread A unlocks the mutex; it could be 
descheduled immediately after it sets the volatile flag, allowing A to 
unlock and relock straight away.  I don't expect the results of this to 
be disastrous, as A will presumably give B another chance the next time 
it polls the flag, but it's not a very reliable means of communication.

Ben.