[Bug nptl/5551] pthread_cond_signal() doesn't return EINVAL for uninitialized cond per POSIX.

["rsa at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From rsa at us dot ibm dot com  2008-01-09 21:12 -------
Jakub,

Isn't there a potential thread-safety issue with the way things currently are?

Given the test-case, if the pthread_cond_signal() in the main thread executes
prior to the memset which zeros out the condition variable following it's
destruction in pthread_cond_destroy() there will be deadlock because the
condition variable, in it's undefined state, still holds a lock.

I tried offering a patch [http://sourceware.org/bugzilla/show_bug.cgi?id=5551]
to at least release the condition variable lock in pthread_cond_destroy() but
Ulrich rejected it as dangerous.

I suppose a user level solution to this problem is to use a mutex to protect the
condition variable array thereby allowing the condition variable to be
exclusively locked and zeroed.

I just want to make sure that this isn't an oversight.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5551

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.