Re: Comments on the thread library

From: williamkempf_at_[hidden]
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 
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?

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 
specific
> really bad behavior", because it allows an implementation to do 
something
> more reasonable (e.g. throw an exception).

This is (partially) why Boost.Threads doesn't have an Unchecked mutex 
type.
 
> > 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!

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.

Bill Kempf