Dear All,
Speaking from an implementors point of view I will back up Paul's statement
that the code is indeed quite likely to lead to a pthread_create or
pthread_cond_signal
(for recycling a thread from a holding sigsuspend in a recycling pool,
though a
non-busy wait in a recycling pool could just as well be achieved by a mutex
lock).
On top of this one can refer to Butenhof's popular book (as common ground
that everyone
knows of: p89) "1. Whatever values a thread can see when it calls
pthread_create can also
be seen by the new thread....".
However, do you feel that the pthread_create must necessarily
be in the implementation of thread 'start' and not in the 'new'?
I would think that it may well be just as well
part of the constructor - in that "an OS thread is created at the same
time as a Java thread"
seems a natural mental model and thus a good design.
This would put the fence between Foo.x and Foo.y and only the first would
be guaranteed
visible. I believe that in the absence of further specification this is
the natural semantics that someone
familiar with pthreads programming would map to Java threads.
In the matter of working out 'what to implement' this group is doing
important work.
In terms of the 'how' there are four subtle gotchas I think: register
caching of
variables , compiler code reordering in over eager optimisations, out of
(program)
order processor instruction execution and cross cache visibility introduced
by weak
consistency/relaxed memory architectures. Making knowledge of these
things
unnecessary for normal Java programmers is to some
extent the job of us back shop JVM implementors but it can only be as good
as the
foundations it is based on, so keep up the good work and keep picking
away at
those difficult questions, thanks.
Gordon Hutchison
Memory, Monitors, Threads, Signals
JVM Development,
IBM Java Technology Centre,
Hursley, UK.
Notes: Gordon Hutchison/UK/IBM
Internet: gordon_hutchison@uk.ibm.com
Phone: (+44)/(0) 1962 815646 (Internal IBMUK-245646)
Paul Jakubik <pjakubik@dallas.objectspace.com> on 06/12/2000 05:03:38 PM
Please respond to Paul Jakubik <pjakubik@dallas.objectspace.com>
To: javaMemoryModel@cs.umd.edu
cc: (bcc: Gordon Hutchison/UK/IBM)
Subject: RE: JavaMemoryModel: Question about _current_ semantics of start
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
-------------------------------
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