Why is the only reasonable answer that both writes are visible?
As long as the Java Threads are implemented over pthreads, then both writes
should be visible since t2.start would probably call pthread_create or
possible pthread_cond_signal. Both of these are supposed to have the
behavior that you want.
But what about green threads? Is it unreasonable that at the time you create
a thread using a library like green threads that the Thread object would
copy the context of the thread that created it? Then if that context changes
between the thread creation and the thread start, there would be no reason
that t2 would see those updates.
To me it seems reasonable that there may be non-native threading
implementations out there where the update to Foo.x would be visible, and
the update to Foo.y would not be visible inside of t2.
--Paul
-----Original Message-----
From: Bill Pugh [mailto:pugh@cs.umd.edu]
Sent: Saturday, June 10, 2000 9:33 PM
To: javaMemoryModel@cs.umd.edu
Subject: JavaMemoryModel: Question about _current_ semantics of start
Assume thread T1 executes the following code:
Foo.x = 1;
Thread t2 = new Thread(task);
Foo.y = 2;
t2.start();
The question is, which writes is t2 guaranteed to see without the
need for any synchronization?
The spec isn't clear on this point, but the only reasonable answer is
that t2 is guaranteed to see both the writes to Foo.x and Foo.y.
Certainly, the revised spec will require that.
I ask because Allen Holub was under the impression that only things
done before the thread creation were guaranteed.
From the JVM point of view, this means that a start() call acts
(roughly) as a memory barrier. Actions before the call to start
cannot be moved to after, and an an SMP, an actual memory barrier
would be required under models such as RMO.
Now, given our recent experience with volatile, I suppose I shouldn't
take anything for granted.
Can we get some feedback from some of the JVM implementors on the
list? Is it clear that this is the only reasonable semantics for
start, and have you implemented the required compiler/memory barriers?
Thanks,
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT