Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-04-03 09:04:28

--- In boost_at_y..., Jeremy Siek <jsiek_at_l...> wrote:
> On Mon, 2 Apr 2001, Matthew Austern wrote:
> auster>
> auster> I don't agree with that last sentence. If you need more
than one class,
> auster> it does not follow that the only solution is to have a
generative system.
> auster> Maybe the right solution is just to have more than one
> auster>
> True, though whether we go with the generative or the many class
> (or one on top of the other as others have suggested), we need to
> which combinations of features we care about. The combinations
should at
> least include those that Jens listed in his previous email. Here's
> combinations I think are important.
> non-recursive
> -------------
> basic_lock + try_lock, unchecked
> basic_lock + try_lock, checked
> basic_lock + try_lock + timed_lock, unchecked
> basic_lock + try_lock + timed_lock, checked
> recursive
> ---------
> basic_lock + try_lock
> basic_lock + try_lock + timed_lock

Including a try_lock for all of these types is problematic on Win32.
Not all Win32 platforms support a try_lock concept using critical
sections, and using a Mutex instead leads to performance degradation
on the scale of the pthread implementation that sparked this debate
off. (Though I've recently been pointed at a site that maintains
critical sections can cause worse performance than Mutexes when lock
contention is high. For many uses, however, the faster critical
section is still the right answer.)

There's also a problem with explicitly requiring unchecked semantics
for pthreads. Many pthread implementations don't have an unchecked
locking semantic. For instance, for pthread-win32 all mutex types
are recursive, like it or not. Documentation I've read for pthreads
indicates that there are implementations that supply checked
variations only, though I couldn't venture to guess what
implementations do this. For portability + efficiency the best you
can do is included checked and _unspecified_ locking policies.
> For the sake of simplicity, the above list ignores options for owner
> priority, blocked priority, acquisition scheduling, and interprocess
> mutexes... perhaps we can design things in such a way that we could
> options for these features at a later time.

The concepts are well defined. It's trivial to add new Mutex types
following these concepts that use different locking semantics. For
instance, adding a "named mutex" type that's cross process visible
would simply require adding a new mutex type that follows the same
concept design but includes a constructor taking the name of the
mutex. Implementation is trivial. This was the idea behind the
design and why a minimalist set of mutex types was included. It
seems to me that we either need to add a try_lock to fast_mutex (and
compromise the Win32 implementation a bit) or add a fourth mutex type
that includes try_lock capability. Either of these would be enough
to satisify the concern about pthread speed, remain minimalist, and
still provide an easy path for extension for more platform specific
mutex types.

Bill Kempf

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