Re: Comments on the thread library

From: williamkempf_at_[hidden]
Date: 2001-04-03 12:59:30

--- In boost_at_y..., Jeremy Siek <jsiek_at_l...> wrote:
> Hi Bill,
> 
> Ok, so what I get from what you are saying is that try-locking also 
needs
> to be treated orthogonally.

Possibly.  That depends on whether we need to provide every possible 
mutex type, or if a lowest common denominator is enough.  I went for 
LCD and still think it's the proper decision, but I'm much more 
willing to listen to arguments on this then I am to listen to 
arguments about generative interfaces (that may sound too harsh... a 
generative approach *may* be used later, but for initial publishing 
and proof of concept it would be a bad idea).

> Here's one question. Is there anything to be gained by bundling the
> different locking mechanisms (basic, try, timed) into a single mutex
> class. Would it be simpler to have separate mutex classes for each?

fast_mutex contains only basic locks.  I was a little biased by Win32 
threading primitives (though this topic was discussed early on in the 
design) where timed locks exist, and if you've got a timed lock 
you've automatically got a try lock, so mutex jumped right to 
including all three types.  I could be convinced that a third mutex 
is needed for inclusion of only try locks, though that means the 
types for the recursive mutexes will likely need factoring out as 
well.  If an LCD approach is not good enough we'll need 9 different 
mutex types:

unspecified checked recursive basic try timed
X                             X
X                             X     X
X                             X     X   X
            X                 X
            X                 X     X
            X                 X     X   X
                     X        X
                     X        X     X
                     X        X     X   X

> Bill, perhaps you could post a revision of the table below showing
> what you envision?

See above.  I don't necessarily envision this.  I'm still leaning 
towards an LCD approach.  I think the current implementation is fine, 
but if the pthreads implementation still bothers people that much 
(and I hope they've taken into consideration that fast_mutex should 
handle 98% of the cases that they think mutex is to slow for) then 
I'd vote first for adding only one more mutex type that is a 
fast_mutex with a try_lock added.
 
> 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 so you'd prefer to 
specify Unchecked so the known behavior is a deadlock.  In some cases 
you can't specify this (usually because of performance reasons) and 
so an Unspecified policy is used.  Because of portability concerns no 
Boost.Threads types are Unchecked but for classifying the possible 
behaviors the documentation can't simply wrap the two policies into 
one.

Bill Kempf