[Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

[triegel at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25847

--- Comment #17 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Arun from comment #3)
>     MUTEX_LOCK(gil->mutex);
>     _Py_ANNOTATE_RWLOCK_RELEASED(&gil->locked, /*is_write=*/1);
>     _Py_atomic_store_relaxed(&gil->locked, 0);
>     COND_SIGNAL(gil->cond);
>     MUTEX_UNLOCK(gil->mutex);
> 
> #ifdef FORCE_SWITCHING
>     if (_Py_atomic_load_relaxed(&ceval->gil_drop_request) && tstate != NULL)
> {
>         MUTEX_LOCK(gil->switch_mutex);
>         /* Not switched yet => wait */
>         if (((PyThreadState*)_Py_atomic_load_relaxed(&gil->last_holder)) ==
> tstate)
>         {
>             assert(is_tstate_valid(tstate));
>             RESET_GIL_DROP_REQUEST(tstate->interp);
>             /* NOTE: if COND_WAIT does not atomically start waiting when
>                releasing the mutex, another thread can run through, take
>                the GIL and drop it again, and reset the condition
>                before we even had a chance to wait for it. */
>             COND_WAIT(gil->switch_cond, gil->switch_mutex);
>         }
>         MUTEX_UNLOCK(gil->switch_mutex);
>     }
> #endif
> }

Can you please check whether you are using condvars correctly in your code, in
particular whether your code handles spurious wake-ups of COND_WAIT correctly? 
The bits of code you have posted do not have a loop that checks the wait
condition again; there is just an if statement and you unlock the mutex right
after the COND_WAIT.

Also, the two critical sections seem to use different mutexes and different
conditions.  It would be more helpful if you could show code examples for pairs
of related signals and waits.

The use of atomic access to the condition within the critical section (
gil->last_holder) can make sense, but it should not be required because that's
what the mutex / critical section takes care of in a typical use of condvars. 
Perhaps check that as well. 

Ideally, a small reproducer would be best.  (I'm aware of the first reproducer
posted, but I'm currently looking at it and am not yet convinced that it is
correct; it sends out more signals than the number of wake-ups it allows
through the wait condition, AFAICT, which I find surprising.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.