[concurrency-interest] Propagation of signals tonon-interruptedthread

Martin Buchholz martinrb at google.com
Sun Nov 13 23:13:12 EST 2011


>
>
> I still oppose this and see little point in it. Why guarantee something
> only to then say that noone should be acting based on the guarantee? What
> do you gain by this? The ability to change a while loop to an if-statement
> - and what does that gain you, a saving of  one comparison and one branch
> in a code block that suspends a thread ???
>

As a practical matter, enough programmers have made the mistake (?) of
depending on the current no-spurious-signal guarantee.  jsr166 has too many
users to reverse this implementation decision now - it must be enshrined in
the spec.  In fact, the jsr166 tck tests themselves are incorrect in making
this assumption.  I considered "fixing" them, but I couldn't bring myself
to weaken/complexify the tests when we could just go ahead and trivially
fix the spec instead.

In cases where conditions represent irreversible state transitions, it
seems not unreasonable to me to discard the loop, e.g.

        lock.lock();
        try {
            if (!isTerminated())
                termination.await();
        } finally {
            lock.unlock();
        }

the code will still work while being marginally more efficient, and there's
probably lots of code out there depending on that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111113/adaf454c/attachment.html>


More information about the Concurrency-interest mailing list