Michael Glassford wrote: [...]
Thanks. That's what I thought, but I wanted to make sure.
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). 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). 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. regards, alexander.