Victor Luchangco <victor_l@raven.lcs.mit.edu> writes of thread
creation and termination detection using Thread.join:
> 1. Am I correct that at the end, val could be 5 or 0?
> (I have sequences of load, store, etc. actions that I believe are
> correct according to JLS.)
>
> 2. If so, does this behavior seem acceptable to others?
>
> 3. Do proposals for the new JMM fix this problem (assuming it is a
> problem)? If so, could you point me to these proposals?
First of all, my recollection was that the old Chapter 17 spec was
silent on these points, and you could thus say that anything goes.
For (1) you're basically asking whether a started thread inherits the
state of the thread which started it, and whether after a join the
current thread sees the state of the joined thread.
I would answer yes in both cases. Our OOPSLA paper didn't come out
strongly on this; we said that a child could see the memory state of
the parent which started it, which I think is all we're looking for
here. The creation of a thread object is of course governed by the
semantics for constructors (I think we all agree those semantics ought
to prevent you from ever seeing uninitialized garbage).
I'd be perfectly happy making the same assertion about
Thread.join---that the joining thread will see all state changes made
in the terminated thread. In the language of CRF, this would require
something like this at the end of every thread (ie at the end of the
Thread.start method after run has returned):
Commit *; // All writes are commited to memory
Fence_WW *, thread.terminated; // Before we indicate termination.
signal thread.terminated
[then the thread ceases to execute]
Then join looks something like this:
await thread.terminated;
Fence_RR thread.terminated, *; // Make sure we see thread's effects
Reconcile * // in all subsequent reads.
I can't think of any reason *not* to guarantee this level of
consistency, and I can't think of any simple way to add it if the
guarantees are not provided. On the other hand, I'm content enough
with this solution that I've seen no reason to look harder.
-Jan-Willem Maessen
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT