"Boehm, Hans" wrote:
> If I understand this correctly, I wonder about the feasibility of the
> optimizations. It looks like we would have to optimize out
> MonitorEnter/MonitorExit on an object that's accessible from multiple
> threads. That seems extremely hard. Even if you could prove that the
> synchronization is not necessary to protect the object itself (e.g. because
> it doesn't change after it becomes visible), as far as the compiler is
> concerned, it could be use to protect something else. Even a
> MonitEnter/MonitorExit pair, with nothing in between, is far from a no-op:
>
> 1) It's currently a memory barrier, though I guess that may change, and
If you remove a synchronization operation on a thread-local object, you can't
just remove the monitorenter and corresponding monitorexit bytecodes.
Technically you need to keep the memory barriers associated with that
operation, but you can remove the locking associated with it. If you remove the
memory barriers, then threads may not see updated results and may--in the worst
case, I think--stop making progress. However, I think this case only occurs if
the original program does not properly synchronization its code (i.e. there is
a data race). Is there a situation where removing the memory barriers
associated with the monitor of a thread-local object will have adverse effects
on a properly synchronized program? (When I say "properly synchronized," I mean
that all threads lock the same lock before accessing a shared field or object.
Are properly synchronized programs even attainable?)
> 2) It can often be used to ensure that another thread has made sufficient
> progress, e.g. if a parent thread holds the lock during thread creation, the
> child may acquire and immediately release it to ensure that the parent has
> finished some work associated with thread creation.
In this situation, if I understand it correctly, a parent thread is
synchronizing on some object and a child thread is synchronizing on the same
object. This object is accessible by multiple threads and hence not
thread-local. You cannot remove the child's empty synchronization block if the
parent is doing some work that is visible to the child.
Jeff
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT