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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
