[Boost.Thread] self deadlocking issue
Hi, all
I was debugging a buggy program which could be simplified as below:
#include
Cheng Lian
Hi, all
I was debugging a buggy program which could be simplified as below:
#include
using namespace boost;
mutex m;
void f() { mutex::scoped_lock lock( m ); }
int main() { mutex::scoped_lock lock( m ); f(); return 0; }
I think this would definitely self deadlock and the program should be waiting forever. And my Debian Linux box proved that true. But on my XP (with SP2) box, the program didn't dead lock and everything pass through! Seems that on Win32 platform, the mutex is recursive? I checked the code and only CRITICAL_SECTION related is found around the lock/unlock lines. But I think CRITICAL_SECTION itself is not recursive. Then why? Thanks for response.
Windows CRITICAL_SECTIONs are recursive. The 1.34 boost mutex is based on a CRITICAL_SECTION, so is therefore also recursive on Windows. The 1.35 mutexes will not be recursive on Windows. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
http://boost.org/doc/html/thread/concepts.html#thread.concepts.locking-strat... Cheng Lian wrote:
I think this would definitely self deadlock and the program should be waiting forever.
No, the behavior is operating system dependent. See e.g. http://boost.org/doc/html/thread/concepts.html#thread.concepts.locking-strat... "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." Boost thread currently only provides: "unspecified locking strategy." roland aka. speedsnail
participants (3)
-
Anthony Williams
-
Cheng Lian
-
Roland Schwarz