This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/12875] pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]