> From: Doug Lea [mailto:dl@cs.oswego.edu]
> I wrote:
> > 1) Synchronize around all reads and writes to B and its
> fields. Should work
> > on current implementations. Moderately expensive to very
> expensive, though
> > perhaps not in the Beans context?.
>
> For the specific case of JavaBeans that are auto-generated via IDE
> tools, the tools should by default synchronize setX/getX
> methods anyway
> (and, sometimes insert synchronized PropertyChangeListener code).
> Does anyone know if they do? If so, the resulting classes are good
> candidates for application of the kinds of sync-removal algorithms
> Jeff mentioned.
>
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
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.
Did I miss something? Is there a known algorithm to do this safely?
Hans
-------------------------------
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