Re: Fixes for generic pthread_cond_*wait functions

[email protected] schrieb am 11.03.03 20:11:56:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alexander Terekhov wrote:
> 
> > IMO the right "fix" for the second one is nothing but abort(). 
> 
> THere is nothing like this in the standard.  

That's correct.

>                                              In fact, no correct program
> can fail this way since you would have to do something to the mutex in a
> signal handler which isn't allowed.  

Not only. Another thread might simply destroy the mutex and THAT 
might result in a [EINVAL] failure to reacquire the mutex, for
example.

>                                     Still, reporting the problem is
> fine.  If you don't like it, file an interpretation request.

Well, I think that the *initial* call [mutex-instance-wise] to 
pthread_mutex_lock() function shall be allowed to fail with 
some "resource-not-available" error (lazy initialization for 
the statically initialized stuff comes to my mind). You are 
quite correct pointing out that in the case of 
pthread_cond_wait() and pthread_cond_timedwait() functions, 
this is not the case since we REacquire the mutex here. 

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. That
is why I suggest to abort() instead. This treads into the issue 
of "quality of implementation", I think.

> 
> 
> > - a rather mysterious "cbuffer.oldtype" beast;
> > 
> > - lack of some measure(s) to ensure that a canceled thread does 
> >   NOT consume a "concurrent" signal -- "A thread that has been 
                                ^
                                |
condition >---------------------+

> >   unblocked because it has been canceled while blocked in a call 
> >   to pthread_cond_timedwait() or pthread_cond_wait() shall not 
> >   consume any condition signal that may be directed concurrently 
> >   at the condition variable if there are other threads blocked 
> >   on the condition variable."
> > 
> > Or am I just missing and/or misunderstanding something?
> 
> What is your problem?  If the signal handler is called no condvar signal
> is used.

I meant "condition signal"; (B) below. My problem is this: 

A) "....
    if (!(cbuffer->oldtype & CANCELTYPE_BITMASK))
    ....
    cbuffer.oldtype = __pthread_enable_asynccancel ();"

   Unless I'm just missing and/or misunderstand something, the 
   unwinding *might* occur before "cbuffer.oldtype = ..." is 
   completed. 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.


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. Uhmm,
   __condvar_cleanup() could simply issue an extra signal, for 
   example. This might be similar to a possible solution to a 
   "problem" that's illustrated in the following thread:

   groups.google.com/groups?threadm=3DF72135.2FA3F240%40web.de

regards,
alexander.

______________________________________________________________________________
Mit der Auslands-SMS von WEB.DE FreeMail erreichen Sie Ihre Freunde auf
der ganzen Welt - http://freemail.web.de/features/?mc=021171