Boost logo

Boost :

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?


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