id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
3354,"regex's static_mutex.cpp passes ""false"" to scoped_lock's constructor",mdorey@…,John Maddock,"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:

         m_plock = new boost::recursive_mutex::scoped_lock(*static_mutex::m_pmutex, false);

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.

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:

        template<typename TimeDuration>
        unique_lock(Mutex& m_,TimeDuration const& target_time):

Clearly, the intention of this code wasn't to wait on the lock for up to zero TimeDuration 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:

      if(0 == m_plock)
         m_plock = new boost::recursive_mutex::scoped_lock(*static_mutex::m_pmutex, false);
      m_plock->lock();
      m_have_lock = true;

Earlier in the file, there's a similar bool which is definitely used this way:

scoped_static_mutex_lock::scoped_static_mutex_lock(static_mutex& , bool lk)
: m_plock(0), m_have_lock(false)
{
   if(lk)
      lock();
}

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.",Bugs,closed,Boost 1.40.0,regex,Boost 1.39.0,Problem,fixed,,