Hi Bill,
> -----Original Message-----
> From: Bill Pugh [mailto:pugh@cs.umd.edu]
>
> The things David has proposed are generally along the lines of what I
> have been proposing.
My apologies for not attributing things directly to you. I lost track of
who suggested what in what context and so simply threw together what looked
like a coherent and complete set of suggestions. Any errors in the
interpretation are mine :)
> * The requirements having to do with final non-static fields
> are just part of a safety guarantee. For correctly synchronized code, it
> never needs to come into play.
It's not clear to me what your suggestion does in the following case.
Suppose that thread 1 creates an object that consists only of final fields
and publishes it to a shared non-volatile and non-final reference. If
thread 2 accesses the object is it guaranteed to see the final values of
the final fields? My take on this is yes - this allows the optimisation of
removing the volatile flag on the reference to a truly "immutable" object.
> * Allowing array elements to be final and/or volatile is going to be
> very difficult. Amoung other things, it would change the signatures
> are encoded and complicate subtyping relationships (is an
> array of final refs to Strings a subtype of an array of non-final refs
to
> Objects)?
Hmm - I had overlooked the subtleties of assignment. My apologies to Josh
for over trivialising this issue - it is more complex than I had perceived.
But as I said it is still a secondary issue.
> I think I can make something work so that a final ref to an
> array will give us the same guarantees for the array elements that we
> have for the ref.
This would be nice but given the mutability of the array elements I'm not
sure what could actually be achieved in practice.
> * The semantics of allowing memory barriers associated with
> useless locks to be removed is actually quite clean. You just say that
> rather than having a model of a global memory, that updates flow between
> threads via monitors and volatile variables. If thread 1 unlocks X, and
then
> thread 2 locks X, then thread 2 sees all of the updates of thread 1.
Okay I think I understand this. However I'm not clear what impact
"incidental" synchronisation will have on this. For example, consider the
animation loop which does:
while(!terminated){
updateState();
repaint();
Thread.sleep(50);
}
and a quit method: public void quit(){ terminated = true; }
I'm not so much concerned with sleep() ( we could define sleep to
synchronise on a per-thread monitor and hence never involve communication
between threads). However, repaint() ultimately ends up accessing the
single event queue which could quite reasonably be expected to involve
synchronisation. If quit() is invoked as part of an event handler then the
event thread will execute it and thus it too will synchronise access to the
event queue - hence comunication between the two threads will take place
via a common monitor. This precludes the compiler from storing 'terminated'
in a register (say) even though it is not volatile, unless it can do a full
analysis of the code paths followed in the loop including the use of native
code!
I'm not sure what my point is here other than pointing out that a compiler
may have trouble taking advantage of non-volatile references due to the
possibility of indirect, or incidental, synchronisation.
Cheers,
David
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT