[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

["triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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.