Boost logo

Boost :

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
> > Not all Win32 platforms support a try_lock concept using critical
> > sections, and using a Mutex instead leads to performance
> > on the scale of the pthread implementation that sparked this
> > off. (Though I've recently been pointed at a site that maintains
> > critical sections can cause worse performance than Mutexes when
> > 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
> > for pthreads. Many pthread implementations don't have an
> > locking semantic. For instance, for pthread-win32 all mutex
> > are recursive, like it or not. Documentation I've read for
> > 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
> > 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
> 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

> In my mind, Boost is always to get a balance between benefiting most
> users and not punishing users who have standard featuers. For
> Some workaround for VC++(benefiting most users), using partial
> specialization if supported(not punishing users). However, the
> is a kind of encouragement of staying in a legacy status from
> point of view. (I am not saying that it is bad to provide
> after all, a portion of users get benefits from that.) Does a
> 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

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

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