At 8:25 PM -0700 10/22/01, Cliff Click wrote:
>Bill Pugh wrote:
>>If, instead, we had:
>>initially, all variables are 0
>> Volatile1 = 1
>> while (Volatile1 == 0);
>> print "success"
>>Then the program would be guaranteed to print "success", because
>>once thread 1 terminates, thread 2 must see the change to Volatile1
>>and then terminate.
>Why must Thread 1 get any time slices at all?
>Why can't Thread 2 grab the first time slice and all remaining slices?
Ah, you are correct. Even with a "some thread makes progress" rule,
this example doesn't have to print "success".
This is why we are building an implementation of the semantics,
rather then relying on my quick analysis of what the semantics would
mean for any particular example.
At 1:20 PM +1000 10/23/01, David Holmes wrote:
>First point: the thread in the infinite loop *is* making progress. It's not
>doing anything useful but it is progressing exactly in accordance with the
>code that was written.
Correct. So if you have any non-terminating threads, the level of
guarantees are lower than for a program where all threads are
guaranteed to terminate.
At 7:27 AM -0400 10/23/01, Doug Lea wrote:
>While changing scheduling semantics of Thread.yield probably fall
>outside JSR-133, it might be worth thinking about memory rules to
>associate with it that would improve portability.
I agree that it would be nice to think about what such changes might
be, even if we don't make them part of this JSR. For example,
Thread.yield() allows all other threads of equal or higher
priority a chance to make progress.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:36 EDT