This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 20 Sep 2012 16:21:01 +0000
- Subject: [Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
- Auto-submitted: auto-generated
- References: <bug-13165-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13165
--- Comment #26 from Torvald Riegel <triegel at redhat dot com> 2012-09-20 16:21:01 UTC ---
(In reply to comment #24)
> Although I agree that the spec allows this interpretation, I think it is highly
> impractical and unintuitive, that's why I believe it is not what the authors
> had in mind. But of course, the only resolution of this argument at this point
> is to ask them for clarification. So I don't see any point in arguing any more
> without involving them.
If the requirements in the specification should change in the future, we can
look at this again. I personally don't think that this makes cond vars
significantly impractical or unintuitive, but that is a trade-off that the
standards body will have to make (or probably did when it produced the current
spec).
Until then, I suppose that you now agree that this is correct behavior
according to the current spec.
> Meanwhile, just consider this: you have code in the implementation which tries
> to prevent spurious wakeups and it basically aims to establish a timeline of
> the calls to pthread_cond_signal() and pthread_cond_wait()
Not a timeline, but just overall number of signals or threads that started
waiting.
> and assumes that a
> wakeup is spurious if it occurred without a signal being sent after the
> respective thread blocked.
It is spurious if there were not enough signals being sent, or other threads
consumed the signals that were sent.
> I dare say that the code suggests that whoever wrote
> this code had the same assumptions about ordering as me.
Looking at the git log for the respective files, you should take that question
to Ulrich or Jakub.
> And it actually
> contradicts your interpretation, because with your interpretation a single
> counter of outstanding signals would be enough.
I doubt that (if you want to do this efficiently).
> BTW, the reason why this code fails to work correctly is very simple - you
> can't detect spurious wakeups reliably using constant memory without giving up
> all ordering guarantees.
I think you can (just combine something like a ticket lock with the futex) --
but this won't be efficient.
--
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.