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 23:00:28 GMT
Yep, I'll do this

On 11/20/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> 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
> >
>

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