Re: Comments on the thread library

From: williamkempf_at_[hidden]
Date: 2001-04-03 12:32:15

--- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:
> At Tue, 03 Apr 2001 14:04:28 -0000,
> William Kempf wrote:
> > 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.
> 
> I guess that pthreads implementations in most of unix flavor OS ( I
> checked four OS's, IRIX64-6.5, Solaris-2.7 and Linux-2.2.x 
ix86/alpha)
> provided unchecked locking semantics. I donot know if Windows native
> threads supported unchecked  locking semantics or not. 

Unless the pthreads implementations you checked support the 
PTHREAD_MUTEX_ERRORCHECK type (I'm guessing they don't, since this is 
a new addition to the standard, but I'm not a pthreads expert so may 
be way off base here) then regardless of how "normal" pthread_mutex_t 
types work for these platforms you can't bet on this behavior.  The 
older POSIX standards specifically stated that attempts to 
recursively lock a mutex results in undefined behavior.  You're 
advocating the equivalent of making use of undefined C++ behavior 
that "all known implementations behave this way".  We won't do this 
for the C++ standard, so we should not do it for the POSIX standard 
either.

> In my mind, Boost is always to get a balance between benefiting most
> users and not punishing users who have standard featuers. For 
example,
> Some workaround for VC++(benefiting most users), using partial
> specialization if supported(not punishing users). However, the 
former
> is a kind of encouragement of staying in a legacy status from 
another
> point of view. (I am not saying that it is bad to provide 
workaround,
> after all, a portion of users get benefits from that.)  Does a 
legacy
> system should deserve a little inconvenience (or punishment) in some
> degree so that it will evolve to the better?  Should systems which
> have a feature be punished because a few other legacy systems lack a
> feature?

Very different cases from the one being discussed.  Remove the 
timed_lock from the mutex and we can then optimize the implementation 
according to what mutex types a specific POSIX implementation 
supports (there's macros to help with this), but with the timed_lock 
the more complex implementation is simply required, end of argument.

The whole argument can be boiled down to this:  should boost::mutex 
have a timed_lock, or should we add yet another mutex type that 
supports try_lock?  All the other discussions don't really address 
the problem directly, they just change the over all interface and 
implementation to allow a different method of working around the same 
problem.

I'm tempted to add a try_lock to the fast_mutex and be done with it.  
This punishes the Win32 users instead, but not as greatly.  The only 
problem is that we'll port to XYZ some day and find that this 
decision hurts them.  That's why I originally designed things the way 
they are.  Where lock speed truly matters you're very unlikely to 
need a try_lock (let alone a timed_lock) so you can use the 
fast_mutex and not be punished on any platform.  If your needs are 
different than this (i.e. you need more than a simple locking 
implementation but you need maximum performance as well) you're needs 
are basically platform specific any way... you're going to 
be "punished" on _some_ platform.

Bill Kempf