Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk