From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-02-11 04:33:50
Ulrich Eckhardt <doomster <at> knuut.de> writes:
> On Friday 08 February 2008 21:33, Jos Hickson wrote:
> > On 08/02/2008, Anthony Williams <anthony_w.geo <at> 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?
Windows native Mutex objects are very expensive to use (as they are Kernel
objects), and CRITICAL_SECTIONs have their own problems (such as lock hand-off
and the lack of a timed_lock facility). The boost 1.35 implementation uses
InterlockedXXX operations to try and avoid waiting on a kernel object, and an
Event object for blocking waits. In my tests, this exhibits greater fairness,
and runs faster on average than either Mutex or CRITICAL_SECTION based
the article I wrote for Overload describing the implementation and rationale.
> > > 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
I have some proof-of-concept code for a mutex that will detect deadlocks and
other undefined behaviour, but it's not production-ready yet.
> > > 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.
Yes, it's undefined behaviour. Quite how that manifests is an implementation
-- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk