Boost logo

Boost :

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-07-10 07:41:04


Hello, Boosters!

Today I stumbled across an unspecified behaviour which can be caused
by the example class "counter" of the Boost thread FAQ.
The errounous lines are inside the copy assignment operator of the
class:

      boost::mutex::scoped_lock lock1(&m_mutex < &other.m_mutex ?
m_mutex : other.m_mutex);
      boost::mutex::scoped_lock lock2(&m_mutex > &other.m_mutex ?
m_mutex : other.m_mutex);

Reasoning: Both the m_mutex member of *this as well as the m_mutex
member of the argument
other are not elements of the same object, so according to 5.9/p.2:
"[..] the results
of p<q, p>q, p<=q, and p>=q are unspecified.".
On the first sight this does not mean so much for the first line (We
just don't know, which one of the
mutexes is chosen), but it can result in an errounous program combined
with the same unspecified
behaviour of the 2nd line. A valid implementation could in both cases
return true (or false) and thus
could lead to two successive trials to lock the same mutex, which would
lead to an lock exception.

I would recommend to either use a deterministic order of locking or
otherwise a coupled
undeterministic method (which ensures, that the 2nd mutex argument is
different from the first).

Greetings from Bremen,

Daniel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk