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/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting


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

--- Comment #24 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 12:46:24 UTC ---
(In reply to comment #23)
> This states something in relation to those threads that are considered to be
> blocked.  It does not state anything about which threads can or have to be
> considered to be blocked.  So, it can't be an upper bound.

It doesn't say "blocked at the time the signal is delivered". It says
"currently blocked". And it doesn't talk about the effect of the delivery of
the signal, it talks about the effect of the function. So "current" and
"function" should be related somehow. I'm taking the relation to be that
"current" means "at the time of the call to the function".

But the language of the standard is too vague to make it explicit what
"currently" means here, so I guess you are free to interpret it otherwise.

> There is a lower bound (or minimum requirement) based on the happens-before via
> the mutex (hence "currently").  The sentence allows the implementation to let
> the signal have no effect if there is no thread that has to be considered
> blocked with the assumption of the lower bound.  Assuming more threads to be
> blocked is the same as allowing spurious wake-ups.

I don't really buy your argument here, but I just realized that this sentence
only talks about the situation when there are no blocked threads, so I cannot
use it to reason about the case when there are blocked waiters before the call.

Again, the vague language of the standard allows your interpretation.

> > If I accept your argument, there will be no way to determine at least a set of
> > threads from which the woken thread will be chosen, so why does the standard
> > talk about predictability?
> 
> There is the lower bound, which does determine properties of this set.

What I meant is that if we accept your interpretation, there are no threads
that can be excluded from the set of blocked threads - except the ones that
never called, nor will ever call pthread_cond_wait() and the ones that have
already returned from all the calls to pthread_cond_wait() they will ever make.

To illustrate this, let me take what you're saying to its logical conclusion.

Suppose for simplicity that we have a single call to pthread_cond_signal() and
many calls to pthread_cond_wait(), both before and after the call to
pthread_cond_signal(). What you are actually saying is that it is correct for
the call to pthread_cond_signal() to consider all of these threads to be
blocked, and is allowed to wake any of them, even threads that are not created
yet.

Even more, if the signaling thread calls pthread_cond_wait() some time (even
hours) after it called pthread_cond_signal(). it is correct (although
undesirable) for it to consume its own signal and all the rest waiters to
become blocked.

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.

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() and assumes that a
wakeup is spurious if it occurred without a signal being sent after the
respective thread blocked. I dare say that the code suggests that whoever wrote
this code had the same assumptions about ordering as me. And it actually
contradicts your interpretation, because with your interpretation a single
counter of outstanding signals would be enough.

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.

-- 
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]