Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk