> We aim to please: it is stated on p19 of the public review draft, in
> Section 6.6. :)
Ok thanks. Mea culpa for not actually going to look.
> I should point out that it is only by definition a no-op because the spec
> defines it that way.
Which is exactly what I meant :)
> Nevertheless, a couple of other examples spring to mind, depending on how
> broadly you define "thread-local" and "code motion". Reentrant locks can
> be eliminated. You can also merge adjacent lock regions. I believe (not
> sure) that we mention both of these things as well.
I'm still working on the basic "roach motel principle: you can move in but
you can't move out. As code motion across a sync block implies a move out
then it can't happen. Removal of reentrant locks, and lock region merging
all constitute "move in" motions as far a I can tell. The no-op for
thread-local sync is the only thing that actually removes the "roach motel"
rules by removing the sync block altogether.
Cheers,
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:58 EDT