Re: [boost] This deadlocks on Linux but not on Windows

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
implementations. See
http://www.justsoftwaresolutions.co.uk/articles/implementing_mutexes.html for
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 
> program.

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
detail.

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