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