Oh, this is bad. Rana, good catch - we need to fix this ASAP. It's an
amazingly simple test. Hangs on x86_64 linux too.
geir
Rana Dasgupta wrote:
On 11/20/06, *Weldon Washburn* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On 11/20/06, Geir Magnusson Jr. < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>>
>> I guess the important question is "does it matter?"
>Until someone brings in a real app that shows existing behavior is a
>problem, it probably does not matter. I am inclined to close 1951
with "not
>a bug".
Hi,
I looked at Geir's interesting test case in 1951. It is always
somewhat suspicious when a behaviour is significantly different from RI.
As it stands, it does not look like a bug. Ordering is strictly
specified only for memory related operations. The java memory model with
respect to same thread operations ( the main thread in the test case )
only specify that reads and writes to the same location are in order...
other operations ( in this case the asynchronous operations resulting
from the interruption of the two threads ) have no pre-ordering....it is
only intuitive to expect the asynch operations to complete in the order
the program issues them.
Without breaking the memory model, it would in fact, be also possible
for an optimizing jit to reorder the operations to issue the interrupt
on the toWait(true) thread before issuing the interrupt on the
toWait(false) thread.
However, while playing with the test case, I modified it to force a
strict ordering in the completion of the asynch operations...forcing the
toWait(false) thread to finsih before the toWait(true) thread. RI
produces output as expected, however drlvm hangs......this does point to
some problems in the DRLVM thread scheduler....( which I think is also
showing up in the original test program, but unfortunately cannot be
proved ). I am attaching the case...
Thanks
Rana
