On Friday 08 February 2008 21:33, Jos Hickson wrote:
On 08/02/2008, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
Clark Sims <clark_sims_boost <at> yahoo.com> writes:
I would like it to deadlock on windows, because I just wrote a large header
file, which assumes that a
deadlock will occur. In fact, I don't know how I am going to program mutex's and locks, if they act like recursive locks on windows, but scoped locks on linux.
The new boost 1.35 implementation of mutexes on Windows are not recursive, and will also deadlock on this code.
How so? And is there a rationale for that?
However, as others have said, there is no sensible use for code that deadlocks --- once you have a deadlock, your code is dead.
There may be no use for code that deadlocks but it is very useful when doing cross-platform development if the behaviour of mutexes are the same especially if the primary development platform is Windows so that you only then see the deadlocks when you switch to Linux.
I'm currently working on a codebase that is way too multithreaded and not really correctly designed. One idea I came across there is that Boost's threading library could offer a diagnostic mode, just like STLport's debug mode with checked iterators. This could be used to detect undefined behaviour, like e.g. locking a non-recursive mutex recursively or maybe even to detect deadlocks (How I wish there was something like that!) in a running program.
It is an implementation detail how the thread library behaves when you are trying to lock a non-recursive mutex recursively.
Just wondering, but isn't it rather called 'undefined behaviour'? I mean the distinction is important, because invoking UB is definitely bad, while IDB is bearable and just a problem of portability. Uli