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?