Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-13 06:39:07

Howard Hinnant wrote:
> On Jul 12, 2004, at 4:39 PM, Peter Dimov wrote:
>
>> The alternative reality would have a mutex with timed_lock #ifdef'ed
>> on _POSIX_TIMEOUTS until conformance arrives.
>
> <sigh>  It isn't just Mac OS X either.  There are other (embedded)
> platforms I've neglected to mention because I'm not positive exactly
> what my NDA is.  But it can get pretty ugly out there in some cases.
> If OS's would just adopt the pthreads knowledge and experience the
> world would be such a better place.  Multithreading is a tough area and
> OS designers aren't necessarily experts in that particular area (and
> I'm not claiming to be either).  And without the proper OS
> functionality, add-on threading libraries are inherently limited. ...
> No point I'm trying to make.  Just being grumpy. ;-)

I understand. However in this particular case I'm not sure that you're doing
your users a favor. Let's say I'm a library/application developer that can
take advantage of timed_lock to provide some enhancements as a QoI, but at
the same time I most definitely don't want to sacrifice performance; i.e.
performance is a priority that far outweighs the optional enhancements
provided by timed_lock. So I'd prefer to use mutex::timed_lock, getting a
compile-time error on platforms that do not support an overhead-free "timed
mutex".

If, on the other hand, the performance loss (~3-5x, I've read) is not a
concern, I can simply emulate the timed mutex myself; your emulation is no
better than mine.