
On Tue, 26 Jun 2007 22:23:43 +0200, John Zorko <jmzorko@mac.com> wrote:
Giovanni,
Thanks for the quick response! However, i'm still confused, since the Boost documentation seems to say that what i'm seeing will not happen. Specifically, in the Threading Concepts documentation at http://www.boost.org/doc/html/thread/concepts.html, the following statements appear:
"Unchecked Locking Strategy With an unchecked locking strategy, when a thread attempts to acquire a lock on a mutex object for which the thread already owns a lock the operation will deadlock. In general this locking strategy is less safe than a checked or recursive strategy, but it's also a faster strategy and so is employed by many libraries.
Boost.Thread does not currently provide any mutex objects that use this strategy."
Is there something that i'm just not understanding?
As pointed out by Giovanni Piero Deretta the locking strategy implemented by boost thread leads to undefined behaviour if a thread attempts to acquire a lock on a mutex object for which the thread already owns a lock (in your case the main thread). This is stated in the documentation: http://www.boost.org/doc/html/thread/concepts.html under the paragraph: Unspecified Locking Strategy "With an unspecified locking strategy, when a thread attempts to acquire a lock on a mutex object for which the thread already owns a lock the operation results in undefined behavior.In general a mutex object with an unspecified locking strategy is unsafe, and it requires programmer discipline to use the mutex object properly. However, this strategy allows an implementation to be as fast as possible with no restrictions on its implementation. This is especially true for portable implementations that wrap the native threading support of a platform.FOR THIS REASON, THE CLASSES BOOST::MUTEX, BOOST::TRY_MUTEX AND BOOST::TIMED_MUTEX USE THIS LOCKING STRATEGY DESPITE THE LACK OF SAFETY" So far, this is the only locking strategy implemented by the boost thread library. Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/