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.