Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at