harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][threading] is harmony-1951 a bug or a feature?
Date Mon, 20 Nov 2006 22:57:14 GMT
On 11/20/06, Weldon Washburn <weldonwjw@gmail.com> wrote:

> On 11/20/06, Geir Magnusson Jr. <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".

   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)

  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...


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message