harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][threading] is harmony-1951 a bug or a feature?
Date Mon, 20 Nov 2006 22:59:33 GMT
can you attach to the JIRA?

Rana Dasgupta wrote:
> On 11/20/06, *Weldon Washburn* <weldonwjw@gmail.com 
> <mailto:weldonwjw@gmail.com>> wrote:
>     On 11/20/06, Geir Magnusson Jr. < geir@pobox.com
>     <mailto:geir@pobox.com>> 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

View raw message