[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fixes for generic pthread_cond_*wait functions

phil-list redhat com schrieb am 12.03.03 00:38:00:
> > However, cancelation aside for a moment, the standard doesn't 
> > provide any means to differentiate a failure to unlock the mutex 
> > from a failure to REacquire the mutex (a failure to REacquire 
> > would result from some "undefined behavior"). Given that, I 
> > don't see any good reason to "throw" a {re-}locking error.
> Sure there is.  It shows something is wrong and the caller then has to
> go to some length to find out what it is. 

Again: unless you'll provide some {implementation -specific} means 
to "differentiate" (see above)... IMO, abort() is much better way 
to "show" that something went wrong with respect to re-locking the 
mutex here.

> > This (and the fact the neither pthread_cond_wait() 
> >    nor pthread_cond_timedwait() is defined to be async-cancel-
> >    safe) makes me wonder why do you need that "cbuffer.oldtype"
> >    things.
> Read the cleanup handler code and the standard.


Now read my cleanup handler code (BTW, it assumes that futex-wait 
itself is a cancelation point that solves the problem of "signal 
stealing"-on-cancelation internally)


and the standard. ;-) 

What am I missing here, Ulrich?

> > B) "....
> >     __pthread_disable_asynccancel...."
> > 
> >    Unless I'm just missing and/or misunderstand something, the 
> >    unwinding *might* occur right at this point. We can consume 
> >    a condition signal -- this is incorrect if there are other 
> >    threads blocked on the condition variable. Something needs 
> >    to be done here to unblock someone else too, I think.
> Again, yes, there is a minute window for a problem.  I've added some
> more wakeup code.  See the next code drop.

I'll do this tomorrow, probably.

Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den
Virencheck fur Ihre E-Mail-Anhange! http://freemail.web.de/features/?mc=021159

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]