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 mutex?
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 HMUTEX?
I have no idea. Well, the following advice is quite reasonable, I guess. (you might want to read this entire thread ;-) ) http://groups.google.com/groups?selm=4087a6d3%40usenet01.boi.hp.com (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.