Date: 2001-04-03 14:12:59
--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> > > About the unchecked semantics... I'm not sure why you have
> > > both "unchecked" and "unspecified". Why not just
> > Because they are very different types. I tried to document this,
> > others have pointed out that I did a bad job. Let me try to do so
> > again here before I change the documentation:
> > Recursive:
> > Attempts to lock the mutex repeatedly by the same thread succeed
> > with an internal ref-count being maintained.
> > Checked:
> > Attempts to lock the mutex repeatedly by the same thread fail
> > some sort of error indication.
> > Unchecked:
> > Attempts to lock the mutex repeatedly by the same thread dead
> > Unspecified (maybe Undefined would be better?):
> > Attempts to lock the mutex repeatedly result in undefined
> > though one of the above strategies is very likey to be the actual
> > strategy used by a given implementation.
> > When ever possible it's best to specify a policy
> Okay so far...
> > so you'd prefer to
> > specify Unchecked so the known behavior is a deadlock.
> That assumes that a deadlock is a useful intended behavior. Is it?
It can be. An Unchecked policy allows for immediate known (bad)
results with out the need for the overhead of checking. An
Unspecified policy may do with out the overhead of checking, but it
also may not give you immediate known (bad) results. It can make
debugging much more difficult since you've entered the land
of "undefined behavior".
> Specifying "undefined" is sometimes a better alternative to "some
> really bad behavior", because it allows an implementation to do
> more reasonable (e.g. throw an exception).
This is (partially) why Boost.Threads doesn't have an Unchecked mutex
> > In some cases
> > you can't specify this (usually because of performance reasons)
> You mean because causing a deadlock might be too slow? It's a
> question, although the thought makes me laugh!
The Win32 platform only has recursive mutex types. Implementing an
Unchecked policy would, ironically, require checking to be done so
the expected deadlock can occur. This would be the performance
reasons I alluded to.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk