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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost