can you attach to the JIRA?
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
>
