harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][threading] is harmony-1951 a bug or a feature?
Date Wed, 22 Nov 2006 10:57:19 GMT
Rana Dasgupta wrote:
>  The test is a simple one and only a small extension of Geir's case. All it
> tries to do is to force the releases to be in the order 1) toStop thread 2)
> toWait thread and fail otherwise. My impression is that this was the intent
> of the original test, that's the order a normal app developer would expect,
> and that's the release order in RI. The fact that perfect java programs
> should do all waits in conditional loops, or that Test2.lock.wait(xx)
> yields by releasing locks and sleep() or yield() yields retaining locks is all
> quite true. But the purpose of this test and its modification was specific.
>  The spec does mention the possibility of spurious wakeups and the
> application coding to protect against it, but I don't think that it
> recommends it as a JVM feature. As I mentioned, there is also nothing
> preventing the optimized compiled code from moving things around and  the
> interrupt being issued to the toWait thread before being issued to the
> toStop thread. If it does this, even the RI would hang( as can be seen by
> moving the toWait.interrupt() before the toStop.interrupt() in the test ).
> Assuming a time order of acquisition/release in concurrent code is not a
> healthy idea anyway.
>  I don't think that DRLVM violates the spec here. The test ,if perfectly
> written, would not cause a hang. And we can choose not to change anything.
> But I don't think that implementing thread.interrupt() with an
> unconditional notifyAll is a good idea. Salikh's change looks simple
> enough.
> But needs to be tested for all kinds of races. I also hope that it will not
> have scaling issues for a very large number of threads.

+1 to each of your points (expected behavior over spec, not using
notifyAll, etc.)

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message