|
Boost : |
From: Jos Hickson (jos.hickson_at_[hidden])
Date: 2008-02-08 15:33:50
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. 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. Admittedly
not writing code that can potentially lock recursively is better and
not sharing data across threads even better still as I have
subsequently learnt.
Jos
> It is an implementation detail how the thread library behaves when you are
> trying to lock a non-recursive mutex recursively. It is within the scope of
> POSIX threads for an attempt to lock a mutex like this to return an error code
> rather than deadlock, which will trigger the BOOST_ASSERT in the mutex
> implementation.
>
> Anthony
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk