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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-19 07:26:22

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
> 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).

No links? What does "posix safety" mean? The ability to destroy a locked
mutex? To unlock a destroyed mutex? Is a CRITICAL_SECTION "posix-safe"? A
HMUTEX?

> 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).

Which versions?

> 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.

Pseudocode? ;-)