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

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

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.