> This is not correct. In the original example we had something like:
Right my mistake - thanks. Given it is impossible to tell if the barrier
actually occurred until after start() is invoked, only the barrier at
start() is actually needed.
> The other issue with David's discussion is that it does not address code
> movement made by the compiler. Do compilers need to treat Thread.start as
> something special? Would it be cleaner to treat any "new" as something
> special? Does one or the other cause implementers more grief?
I've somewhat lost track of the code-motion discussion and what the proposed
rules are at present but I would expect that the compiler can do anything
that doesn't allow an observed effect contrary to the basic memory model
rules. In other words if the compiler can verify that an action before an
invocation to "new", start(), or whatever is completely unaffected by the
invocation and the invocation can not be affected by the action, then the
action can be moved after the invocation. Unless the compiler is very clever
it can not tell this and so will conservatively not move the code. I would
suspect that invocation of a native method will always prevent the Java
level motion of code across that invocation. At the native-code level, in
the JIT, the synchronization points present in the native code (such as in
pthread_create) would themselves act as code-motion barriers (as they should
in a POSIX compliant C compiler).
In practice Thread.start() is still likely to utilise Java level
synchronization to prevent concurrent attempts to start the thread and so
the code motion rules with regard to synchronized blocks will also come into
play. In that sense I don't think we need either a source or JIT compiler to
recognise start() and treat it specially.
David Holmes
-------------------------------
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