Boost logo

Boost :

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
> 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

> 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:

  Attempts to lock the mutex repeatedly by the same thread succeed
with an internal ref-count being maintained.

  Attempts to lock the mutex repeatedly by the same thread fail with
some sort of error indication.

  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

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at