From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-19 08:16:05
Peter Dimov wrote:
> > Note that this illustration/example doesn't provide "posix safety"
> > with respect to mutex destruction if you use try/timed operations
> > on it. "posix safety" is needed for things like lock-protected ref
> > counting when mutex is "part of" managed object (i.e. you destroy
> > the mutex when the count drops to zero).
> No links? What does "posix safety" mean? The ability to destroy a locked
The ability to destroy unlocked mutex... in spite of having some
thread(s) still not returned from unlock() call. For example, posix
barrier doesn't provide similar kind of safety -- you can't safely
destroy a barrier on return of PTHREAD_BARRIER_SERIAL_THREAD (or
any other thread for that matter), only after *ALL* threads have
returned from the wait call. POSIX mutexes and condvars are "safer"
in this respect.
> To unlock a destroyed mutex? Is a CRITICAL_SECTION "posix-safe"? A
I have no idea. Well, the following advice is quite reasonable, I
guess. (you might want to read this entire thread ;-) )
(Subject: Re: pthread_mutex_delete on almost-used mutex?)
---- [...] beware that this is a tricky area of implementation, and you are not entirely unlikely to run into some implementation that's done it wrong by referencing the mutex (e.g., to record performance or debugging information) "on the way out" of the lock operation. While you'd end up with a valid bug report and perhaps a sense of personal justification, you'd still have a program that wouldn't work on that platform. Sometimes, you can't reasonably avoid dynamic and disposable locks; however as a matter of porting pragmatics you're better off sticking to static locks if you can, or to cache and save your "preowned" locks rather than destroying them. ---- > > > Another thing to watch is > > MS event's behavior for timedout waits. Reportedly, on some windows > > version(s), *timedout* waiter on an event/sema may still consume a > > signal (such behavior is OK and even desirable for condvars because > > timedout status there is just an indication of an independent event, > > but it's NOT OK for events/semas because they have state). > > Which versions? "single CPU W2000" and maybe something else. I'll forward to you some details. > > > If/when > > this is the case, the timedout waiter on a "retry_event" must try > > to acquire the mutex (with "-1") and, if succeeded, either unlock > > it and report failure (which makes little sense given "watchdog > > nature" of mutex.timedwait) or just ignore timedout status and > > report success. > > Pseudocode? ;-) Sure. It's the same problem as the NPTL one illustrated here: ("-1" has the same meaning as NPTL's "2") http://groups.google.com/groups?selm=3F9AC8BC.1FEDE451%40web.de&output=gplain http://groups.google.com/groups?selm=x74qxsrde4.fsf%40bolo.xenadyne.com regards, alexander.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk