Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]