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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-13 10:11:59

On Jul 13, 2004, at 7:39 AM, Peter Dimov wrote:

> 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.

How do we serve the client who needs a timed mutex, on every platform, 
and would rather not implement it himself?  If mutex::timed_lock 
sometimes compiles and sometimes doesn't, then that isn't the answer.  
And telling the client that he can just emulate this functionality 
himself is no different than telling him he can just emulate the STL 
himself.  The emulation on platforms with non-native support requires a 
certain amount of expertise, careful coding, and most importantly, 
time.  Must everyone who must have a timed mutex become an implementor 
of it?

I don't have a problem if mutex is allowed to optionally sport a 
timed_lock() member function (presumably only if it could do so with 
"acceptable" cost).  I just don't want to require it to (in case the 
costs are deemed "unacceptable").  I'd rather there exist a timed_mutex 
class with that requirement.  Would this not satisfy both of our 
hypothetical clients?

-Howard