Re: Comments on the thread library

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 
class.
> auster> 
> 
> True, though whether we go with the generative or the many class 
approach
> (or one on top of the other as others have suggested), we need to 
decide
> which combinations of features we care about. The combinations 
should at
> least include those that Jens listed in his previous email. Here's 
the
> 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 
add
> 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