Yep, I'll do this On 11/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
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 >
