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

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

Peter Dimov wrote:
[...]
> > 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? 

The ability to destroy unlocked mutex... in spite of having some 
thread(s) still not returned from unlock() call. For example, posix 
barrier doesn't provide similar kind of safety -- you can't safely 
destroy a barrier on return of PTHREAD_BARRIER_SERIAL_THREAD (or 
any other thread for that matter), only after *ALL* threads have 
returned from the wait call. POSIX mutexes and condvars are "safer" 
in this respect.

>       To unlock a destroyed mutex? Is a CRITICAL_SECTION "posix-safe"? A
> HMUTEX?

I have no idea. Well, the following advice is quite reasonable, I 
guess. (you might want to read this entire thread ;-) )

http://groups.google.com/groups?selm=4087a6d3%40usenet01.boi.hp.com
(Subject: Re: pthread_mutex_delete on almost-used mutex?)

----
[...] beware that this is a tricky area of implementation, and you are 
not entirely unlikely to run into some implementation that's done it wrong 
by referencing the mutex (e.g., to record performance or debugging 
information) "on the way out" of the lock operation. While you'd end up 
with a valid bug report and perhaps a sense of personal justification, 
you'd still have a program that wouldn't work on that platform. Sometimes, 
you can't reasonably avoid dynamic and disposable locks; however as a 
matter of porting pragmatics you're better off sticking to static locks if 
you can, or to cache and save your "preowned" locks rather than destroying 
them. 
----
> 
> > 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?
"single CPU W2000" and maybe something else. I'll forward to you some 
details.
> 
> > 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? ;-)
Sure. It's the same problem as the NPTL one illustrated here: ("-1"
has the same meaning as NPTL's "2")
http://groups.google.com/groups?selm=3F9AC8BC.1FEDE451%40web.de&output=gplain
http://groups.google.com/groups?selm=x74qxsrde4.fsf%40bolo.xenadyne.com
regards,
alexander.