Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-12 12:31:52


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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk