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

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