>
> Do you see a specific requirement for this new
> java.lang.System.runInIsolation(Runnable)method ? I think that the
> difficulty of explaining the sublety of it should not be forgotten. At
> presnet I can't imagine where I would actually apply it; either I'd want
> the semantics of the existing Runnable.run() method or I'd want the
> application isolation of JSR 121. Could you provide some specific use
> cases ?
>
I guess that the trick is getting the semantics of the existing
Runnable.run() method without any untoward surprises. Specifically,
imagine if Runnable 1 was written by one person, Runnable 2 was written by
another, and they were both running on the same SingleThreadedExecutor.
Runnable 1 accesses final fields improperly (i.e., before the end of
construction), and Runnable 2 accesses them properly.
With the current final field semantics, Runnable 2 is not guaranteed to
see the correctly constructed value of the final fields. When this was
brought up on the list, there were some complaints that it was
unacceptable. I could certainly imagine it being frustrating wrt
debugging. So, I tried to find a solution that was acceptable.
As for specific instances, that would depend on the code. Ideally, you
shouldn't ever let any thread see an improperly published final field, but
there is plenty of code out there that does.
I agree with you as to the difficulty of explaining it. I cannot imagine
most folks using it correctly unless it also brought along some other
semantics with it. For example, over on the concurrency-interest mailing
list, I brought up the idea that it might also allow the use of a
different set of ThreadLocals for its scope. This is something that they
have talked about before, and there doesn't seem to be overwhelming
support for it, partially because it isn't all *that* useful (although I
can imagine using it for ThreadLocals, I would also be perfectly happy not
using it), and partially because it is a little tricky to get right.
Veering off slightly more into that territory is the notion that the
Runnable might get its own Thread / Thread-like object. This has other
implications that are still being hashed through.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT