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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-21 10:33:25

Ben Hutchings wrote:

> 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.  

I wonder if Windows semantics differ... the docs for ReleaseMutex are not
very clear on this.

> 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.  

Yes, that's what I though too.

> 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.

I interpret the intentions like this:

1. The simplest way is to for thread A to push data after each job is done,
and for thread B to get data when it wants to, using mutex to protect data.

2. Another approach is for thread A to always hold the mutex, and briefly
unlock it after each job is done. Thread B will wait on the mutex, and
eventually A will unlock the mutex when B waits on it, so B will acquire
the mutex and do the job.

3. Even more complex approach is to make A unlock the mutex only if some
variable is set.

In that case, the situation where B sets the flag, A releases and locks the
mutex and then B tries to lock the mutex is harmless -- B will get the
mutex on the next cycle.

However, this is rather complicated design!

- Volodya