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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-15 09:31:03

Peter Dimov wrote:
[...]
> The mutex::timed_lock situation is a bit more complicated. POSIX labels
> pthread_mutex_timedlock as part of the Timeouts option, and I don't know
> whether this is because many implementations deliberatley do not provide
> timed locks, or because this is a relatively new addition to pthreads. Does
> someone know?

< Forward Quoted >

David Butenhof wrote:
> 
> Alexander Terekhov wrote:
> 
> >Pls read the message attached below. Perhaps you can answer the POSIX
> >related (and also "thinking severals years ahead") question (to the
> newsgroup/list or to me -- I'll forward it then). I mean
> >
> >>The mutex::timed_lock situation is a bit more complicated. POSIX labels
> >>pthread_mutex_timedlock as part of the Timeouts option, and I don't know
> >>whether this is because many implementations deliberatley do not provide
> >>timed locks, or because this is a relatively new addition to pthreads.
> >
> Mutex timeout was devised for the "More realtime extensions" amendment,
> 1003.1d-1999. It's an option that is not required by the base standard
> or any profile (e.g., SUS), and that obviously was not in UNIX 98. I
> expect it is not widely implemented, nor to be a very high priority.
> (It's not in Tru64 or HP-UX, for example.)
> 
> In general, timed mutex operations are of relatively little use to
> general purpose applications in the first place. It's usually pretty
> hard to recover any shared data that may be corrupted because of unknown
> "bad behavior" on the part of the thread that failed to release the
> mutex. Because it's locked, you can't even unlock it, or reinitialize
> it; so you need to be able to dynamically switch to another mutex to
> continue operation. (As well as worrying about what the nonresponsive
> thread might be doing to your data.)
> As a result, there's usually not much you can do other than dump core in
> many cases. There are, of course, exceptions; but that's part of why the
> implementation priority has been relatively low on most systems.
> 
> This really was a feature desired by and intended for the truly "hard
> realtime" embedded system people, specifically for flight control
> systems and such that have no choice but to do "whatever is necessary".
> 
> (By the way, I've had this reply sitting in a buffer for days now, and
> just rediscovered it, entirely by coincidence, under a bunch of other
> windows. I've been having a lot of meetings and "stuff" lately, and this
> isn't the first time I've completely lost track of some message. Sorry.
> ;-) )

regards,
alexander.