https://svn.boost.org/trac10/ticket/3354 <p> This line in libs/regex/src/static_mutex.cpp's scoped_static_mutex_lock::lock() method passes a bool as a second argument to scoped_lock's constructor: </p> <blockquote> <p> m_plock = new boost::recursive_mutex::scoped_lock(*static_mutex::m_pmutex, false); </p> </blockquote> <p> This only happens on non-pthread systems which don't support WINTHREADS, so perhaps this is minority-interest code, which perhaps explains why it hasn't been noticed before. </p> <p> On the particular platform I'm using, scoped_lock is defined as unique_lock of a mutex type which doesn't support timed-waits. unique_lock has an undocumented constructor which gcc has determined as the best match: </p> <blockquote> <p> template&lt;typename <a class="missing wiki">TimeDuration</a>&gt; unique_lock(Mutex&amp; m_,<a class="missing wiki">TimeDuration</a> const&amp; target_time): </p> </blockquote> <p> Clearly, the intention of this code wasn't to wait on the lock for up to zero <a class="missing wiki">TimeDuration</a> units. Other code in the same file leads me to think that the bool is intended to tell scoped_lock to defer taking out the lock. The line following the line in question then takes out the lock: </p> <blockquote> <p> if(0 == m_plock) </p> <blockquote> <p> m_plock = new boost::recursive_mutex::scoped_lock(*static_mutex::m_pmutex, false); </p> </blockquote> <p> m_plock-&gt;lock(); m_have_lock = true; </p> </blockquote> <p> Earlier in the file, there's a similar bool which is definitely used this way: </p> <p> scoped_static_mutex_lock::scoped_static_mutex_lock(static_mutex&amp; , bool lk) : m_plock(0), m_have_lock(false) { </p> <blockquote> <p> if(lk) </p> <blockquote> <p> lock(); </p> </blockquote> </blockquote> <p> } </p> <p> I'm new to boost's thread library, so slap me if I'm wrong, but I'm a-thinkin' that the modern way to do this with boost::defer_lock. And je vous presente un patch in that vein. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3354 Trac 1.4.3 mdorey@… Wed, 19 Aug 2009 01:07:49 GMT https://svn.boost.org/trac10/ticket/3354 https://svn.boost.org/trac10/ticket/3354 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">static_mutex.cpp.patch</span> </li> </ul> <p> s/false/boost::defer_lock/ </p> Ticket John Maddock Thu, 20 Aug 2009 10:43:47 GMT https://svn.boost.org/trac10/ticket/3354#comment:1 https://svn.boost.org/trac10/ticket/3354#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> (In <a class="changeset" href="https://svn.boost.org/trac10/changeset/55683" title="Apply patch from issue #3354. Fixes #3354.">[55683]</a>) Apply patch from issue <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/3354" title="#3354: Bugs: regex's static_mutex.cpp passes &#34;false&#34; to scoped_lock's constructor (closed: fixed)">#3354</a>. Fixes <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/3354" title="#3354: Bugs: regex's static_mutex.cpp passes &#34;false&#34; to scoped_lock's constructor (closed: fixed)">#3354</a>. </p> Ticket