[Boost-bugs] [Boost C++ Libraries] #3354: regex's static_mutex.cpp passes "false" to scoped_lock's constructor

Subject: [Boost-bugs] [Boost C++ Libraries] #3354: regex's static_mutex.cpp passes "false" to scoped_lock's constructor
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-08-19 01:07:07

#3354: regex's static_mutex.cpp passes "false" to scoped_lock's constructor
--------------------------------+-------------------------------------------
 Reporter:  mdorey@…            |       Owner:  johnmaddock
     Type:  Bugs                |      Status:  new        
Milestone:  Boost 1.40.0        |   Component:  regex      
  Version:  Boost 1.39.0        |    Severity:  Problem    
 Keywords:                      |  
--------------------------------+-------------------------------------------
 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/3354>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.