32779 - PR_Interrupt should increment the condition variable's pending notify count before broadcasting on the condition variable.

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P3)

Description

[Wan-Teh Chang]

If the target thread is waiting on a condition variable
(i.e., thread->waiting is not null), PR_Interrupt does
a broadcast on the condition variable to wake up the
target thread.

It is possible for the target thread to be awakened and
start running before the pthread_cond_broadcast call
returns.  If the target thread immediately destroys
the condition variable after being interrupted (a perfectly
legal thing to do because the target thread should not
need to know how PR_Interrupt is implemented), the condition
variable may be destroyed while pthread_cond_broadcast is
still accessing it.  This is exactly what happens when I run
the 'join' test on Mac OS X.  The pthread_cond_broadcast call
fails and returns the EINVAL error.

A fix is to increment the condition variable's pending_notify
field before calling pthread_cond_broadcast and decrement
pending_notify afterwards, similar to pt_PostNotifyToCvar
and pt_PostNotifies in ptsynch.c.  The pending_notify field
serves as a reference count of the condition variable and
prevents the condition variable from being destroyed while
there is still a pending notify on it.

Comment 1

[Wan-Teh Chang]

Attachment: Proposed fix.

Comment 2

[Wan-Teh Chang]

The fix is checked in.
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptthread.c, revision 3.34