This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/12875] pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait
- From: "martin at lispworks dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Mon, 13 Jun 2011 12:39:05 +0000
- Subject: [Bug nptl/12875] pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait
- Auto-submitted: auto-generated
- References: <bug-12875-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12875
martin at lispworks dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #2 from martin at lispworks dot com 2011-06-13 12:39:04 UTC ---
Can you take another look at this please? It isn't about fairness because the
man page (and spec AFAIK) for pthread_cond_signal says:
"The pthread_cond_signal() function shall unblock at least one of the threads
that are blocked on the specified condition variable cond (if any threads are
blocked on cond)."
In the example, only thread A is blocked at the time thread B signals for the
first time, so I think it should wake whatever happens later The blocking of
threads C and D occurs after thread B signals for the first time so shouldn't
be affected by that signal.
The problem is that if pthread_cond_timedwait in thread D reaches its timeout
before thread A has had a chance to increment __woken_seq, then thread D will
claim the signal even though its true reason for waking is the timeout.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.