From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2008-02-10 11:53:21
On Friday 08 February 2008 21:33, Jos Hickson wrote:
> On 08/02/2008, Anthony Williams <anthony_w.geo_at_[hidden]> 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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk