|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-03 13:51:46
----- Original Message -----
From: <williamkempf_at_[hidden]>
> > About the unchecked semantics... I'm not sure why you have
> > both "unchecked" and "unspecified". Why not just have "unspecified"?
>
> Because they are very different types. I tried to document this, but
> 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 with
> some sort of error indication.
>
> Unchecked:
> Attempts to lock the mutex repeatedly by the same thread dead lock.
>
> Unspecified (maybe Undefined would be better?):
> Attempts to lock the mutex repeatedly result in undefined behavior,
> 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?
Specifying "undefined" is sometimes a better alternative to "some specific
really bad behavior", because it allows an implementation to do something
more reasonable (e.g. throw an exception).
> 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 serious
question, although the thought makes me laugh!
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk