Wojtek Lerch wrote:
> No, in my scenario the thread that timed out would verify that
> there are other threads waiting on the condvar (or just woken
> up), and use that knowledge to avoid checking the predicate
> (perhaps the predicate is expensive to check).
I don't think many people would consider a condition variable to be an
appropriate synchronization primitive for predicates that are expensive to
check. A c.v. gives the application the overhead of tracking the predicate
and specifically allows spurious wakeups, which means the implementation can
make you check the predicate as many extra times as it wants to.
I think what you are saying is just barely possible in practice, but nearly
impossible to do even intentionally (and people don't go out of their way to
make things fragile). You would have to know that the other thread was
blocked, as opposed to about to block or done blocking.
You would have to be the only thread that times out. The other threads would
have to not time out (or the other thread that woke up could time out as
well).
Again, this is so bizarre that to penalize many implementations to make it
work doesn't seem to make sense.
> The assumption
> here would be that if I have timed out, then I was not woken by a
> signal; and if I know that there's someone else waiting for a
> signal, then any signal that just happened or is about to happen
> has caused them or will cause them to run and check the
> predicate. In this scenario, I would consider a signal "lost" if
> it did not wake up any of the blocked threads other than the one
> that returns a timeout.
What if it woke up another one that also returned a timeout? You'd have to
be the only thread that does a timed wait. You'd have to know that all the
other threads do untimed waits. That seems like a rather bizarre use case.
I agree, it could happen. And I agree, the standard is not clear about what
it requires from the implementation in this case. However, I think this is a
defect in the standard and was accidental. Why allow spurious wakeups, and
then require the exact same logic to avoid spurious timeouts?
> > But I think the excerpt above is confused anyway. Lost signals are only
> > possible if there are blocked threads. Otherwise, there is nothing to
> > signal.
> The rationale seems to be using a different definition of "lost"
> signals. But in my scenario, the signal is "lost" in your sense
> -- or, if you prefer, "hidden" behind an ETIMEDOUT.
The standards warns about the case where there are *not* other threads and
says a signal may be lost if there is not another thread. This is
incoherent. Your example covers the case, and only the case, where there is
another thread that could have gotten the signal but didn't. So if the
standard was trying to talk about your case, it didn't do so.
DS
|