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 23:06:09 GMT
thx

Rana Dasgupta wrote:
> 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
View raw message