Bug 54408 – Fix Mutex::tryLock() on Windows to work properly with PlatformCondition::timedWait()

• Component: New Bugs
• Status: RESOLVED FIXED

[Chris Rogers]

Fix Mutex::tryLock() on Windows to work properly with PlatformCondition::timedWait()

[Chris Rogers]

Created attachment 82352 [details]
Patch

[Chris Rogers]

The bug I'm seeing without this fix is that tryLock() will always fail on Windows when another thread is waiting on a ThreadCondition.  Here's the pattern:

// Worker thread waiting to be signalled

        {
            MutexLocker locker(m_backgroundThreadLock);
            while (!m_moreInputBuffered && !m_wantsToExit)
                m_backgroundThreadCondition.wait(m_backgroundThreadLock);
        }

.
.
.

    // Another thread has some work and tries to signal (using a tryLock())

    // Not using a MutexLocker looks strange, but we use a tryLock() instead because this is run on the real-time
    // thread where it is a disaster for the lock to be contended (causes audio glitching).  It's OK if we fail to
    // signal from time to time, since we'll get to it the next time we're called.  We're called repeatedly
    // and frequently (around every 3ms).  The background thread is processing well into the future and has a considerable amount of 
    // leeway here...
    if (m_backgroundThreadLock.tryLock()) {            //  <----------------- this will alway FAIL currently on Windows
        m_moreInputBuffered = true;
        m_backgroundThreadCondition.signal();
        m_backgroundThreadLock.unlock();
    }

[Alexey Proskuryakov]

Comment on attachment 82352 [details]
Patch

Seems fine to make this change, although the design seems surprising. Why is the boolean variable shared between threads needed at all? Can you just use wait/signal without a separate boolean variable?

[Alexey Proskuryakov]

I'm wondering if we can use "fast mutexes" on windows instead: <http://msdn.microsoft.com/en-us/library/ms810047.aspx#locks__topic7>.

[Chris Rogers]

Thanks Alexey.  I think you may be right about my use of the bool variable being redundant.  I'll have to look closer at what I was thinking there and may be able to simplify that.  But I'll land this fix first.

I'm by no means a Windows programming expert so I'm not sure about the "fast mutexes"...

[Kenneth Russell]

(In reply to comment #4)
> I'm wondering if we can use "fast mutexes" on windows instead: <http://msdn.microsoft.com/en-us/library/ms810047.aspx#locks__topic7>.

Those look like they're for implementing device drivers...

[Chris Rogers]

Committed r78597: <http://trac.webkit.org/changeset/78597>