[Webkit-unassigned] [Bug 54408] Fix Mutex::tryLock() on Windows to work properly with PlatformCondition::timedWait()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=54408





--- Comment #2 from Chris Rogers <crogers at google.com>  2011-02-14 12:39:34 PST ---
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();
    }

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.