[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1407344216.24324.317.camel@eris.loria.fr>
Date: Wed, 06 Aug 2014 18:56:56 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
Am Mittwoch, den 06.08.2014, 12:15 -0400 schrieb Rich Felker:
> One problem with this is that being woken by a signal isn't the only
> way a cond var wait can end. It can also end due to timeout or
> cancellation, and in that case, there's no signaling thread to be
> responsible for the bookkeeping, but if another thread calls
> pthread_cond_broadcast at this point, it can legally destroy and free
> the cond var, despite the timed-out/cancelled wait still having its
> own bookkeeping to do.
>
> The best possible solution would be if we could eliminate the need for
> this bookkeeping entirely, but I don't see any easy way to do that.
Easy perhaps not. But the futex syscall returns some of the
information that is currently thrown away.
- when returning with 0 from do_wait we can't distinguish if we were
woken up with a FUTEX_WAKE (good) or with EWOULDBLOCK (bad, retry)
- the call with FUTEX_REQUEUE drops the information if some thread
was woken up, the same for the __wake in pthread_cond_signal.
- pthread_cond_broadcast uses FUTEX_REQUEUE and not
FUTEX_CMP_REQUEUE. This could help to ensure that we don't have a
race on _c_seq. If so, we perhaps wouldn't have to hold a lock when
going in the syscall.
I don't know, yet, if this lost information would help in all
cases. But maybe in some and that would lead to a path for
simplification. I'll dig a bit more.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
