JavaMemoryModel: Executors, Thread Pools and Isolation

Date: Fri May 16 2003 - 15:12:29 EDT

Hi folks,

One thing that we had talked about in the past, but had not settled on a
solution for, is the notion that separate Runnables being invoked by (say)
an Executor in the same thread would behave similarly to the way in which
they would behave if they were genuinely separate threads.

This thread started at:

Bill said:

"In particular, say that [given two Runnables, r1 and r2]

a) some other thread has published a reference to an object x while x is
being constructed

b) r1 loads a reference to x in a way that doesn't guarantee the object is
initialized before the reference is loaded

c) r2 loads a reference to x, but uses synchronization to guarantee that
the reference is not loaded until x is completely initialized.

Now, I argue that even if r1 and r2 are run in the same thread, r2 should
see the correctly initialized version of x. Otherwise, "spooky action at a
distance" can cause serious errors in your software."

The notion we have now is to introduce a method called (say) public void
java.lang.System.runInIsolation(Runnable), which invokes the run() method
of its parameter. Anything run inside this method is treated as a
separate thread for the purposes of determining the value of final fields.

The upshot of this would be that the compiler would not be able to
propagate values for final fields into or out of this method. Thus, loads
of final fields by r1 would not be seen by loads of the same final fields
by r2, neither of which would be seen by the rest of the thread.

This is basically a "super-barrier" for final fields; if it isn't used,
the values of the final fields of a given object can be shared arbitrarily
in the thread.

What are your thoughts on this? Is it a reasonable compromise? Does it
have JSR-166 implications (my guess is "yes")? Other names /
implementations are welcome.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT