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? On Jun 26, 2007, at 1:08 PM, Giovanni Piero Deretta wrote:
On 6/26/07, John Zorko <jmzorko@mac.com> wrote:
Hello, all ... [...] boost::mutex g_Mutex;
void f1() { boost::mutex::scoped_lock lock( g_Mutex );
std::cout << "1\n"; }
int main(int argc, char* argv[]) { boost::mutex::scoped_lock lock( g_Mutex );
std::cout << "main\n";
f1();
return 0; }
... under Windows XP SP2 (using VC 8.0), the output is this:
main 1
... however, under Mac OSX 10.4.10 (using Apple's gcc4.0.1), the output is:
main (program hangs)
Trying to lock a mutex from a thread that already owns it in Boost.Threads is undefined behavior. Under Windows (because of the underlying implementation) it happens to work, but it deadlocks on other platforms.
If you really want a recursive mutex you should use boost.thread recursive_mutex instead of plain mutexes. Anyways, consider that recursive mutexes are generally "Considered Harmful" [1]
Also, probably this question belongs to the boost.users mailing list.
HTH,
gpd
[1]: http://zaval.org/resources/library/butenhof1.html _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com