Alexander Terekhov wrote:
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
^^^^^^^^^^^^^^^^^^^^ Err. This CAS/TID-less thing is not safe at all with respect to "posix safety" for mutex destruction.
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.