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

Re: Fixes for generic pthread_cond_*wait functions



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Terekhov wrote:

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

Such a program has no right to expect anything.  Using
pthread_mutex_lock in a signal handler isn't that bad compared to
destroying the mutex.  People doing this deserve what they get.


> 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.  The implementation is not
required to hold the developers hand and diagnose everything.


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

Well, this is easily fixed.  Yes, there is this theoretical race.


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



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


- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+bnLf2ijCOnn/RHQRAmLcAJ9VQjQy9HfQsd+hVzHH0z+D/RJbIgCeN9p0
mUClZ29yv0mb5BCJH568qgQ=
=/ay4
-----END PGP SIGNATURE-----





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