[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 22:39:03

Peter Dimov wrote:
> Michael Glassford wrote:
> 
>>Peter Dimov wrote:
>>
>>
>>>It seems wrong (and the implementation seems buggy), but
>>>as usual, I may be missing something.
>>
>>Alexander Terekhov has mentioned one problem with the Win32 condition
>>variable implementation that I recall (I have the link somewhere but
>>don't see it at the moment); do you have others in mind?
> 
> 
> For a condition being used with a recursive_mutex, condition::wait does:
> 
>         typename lock_ops::lock_state state;
>         lock_ops::unlock(mutex, state);
>         m_impl.do_wait(...);
>         lock_ops::lock(mutex, state);
> 
> The (Windows, for example) recursive mutex stores its lock count in state:
> 
> void recursive_mutex::do_unlock(cv_state& state)
> {
>     state = m_count;
>     m_count = 0;
> 
>     if (m_critical_section)
>         release_critical_section(m_mutex);
>     else
>         release_mutex(m_mutex);
> }
> 
> and restores it in do_lock( cv_state& ).
> 
> However, if there is a thread switch just after m_count = 0, and then the
> recursive_mutex is locked, its m_count would now be 1. After the do_wait,
> do_lock( cv_state& ) will restore the m_count to the original value, and the
> count update caused by the "extra" lock would be lost. Oder?

When I first read this it made sense to me, but now I'm not seeing it. 
It's not possible for another thread (thread B) to lock the recursive 
mutex just after thread A executes m_count = 0 because thread A still 
holds the m_mutex, right?

Mike