[concurrency-interest] Propagation of signalstonon-interruptedthread

David Holmes davidcholmes at aapt.net.au
Mon Nov 14 17:19:47 EST 2011


Martin,

You are going to have to back up statements like that with some hard
evidence. Who is depending on this unstated guarantee and why?

If the JSR166 TCK tests are incorrect then they need to be fixed. Part of
the problem is the distinction between tests against the spec versus tests
of this implementation.

I would be loathe to enshrine this guarantee in the spec for the simple
reason that it is an unprovable and untestable property.

David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Martin
Buchholz
  Sent: Monday, 14 November 2011 2:13 PM
  To: concurrency-interest
  Subject: Re: [concurrency-interest] Propagation of
signalstonon-interruptedthread



    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/20111115/a9e150be/attachment.html>


More information about the Concurrency-interest mailing list