[boost] Re: [Boost.Thread] mutex Win32 implementation changes

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-16 05:47:42

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.