FYI, my perspective of these matters comes from that of a Java
programmer; not one who builds JVMs :-). Some of these term and
concepts are new to me (ex: difference between "load" and "read").
Thomas Wang wrote:
>
> David,
>
> >There are a few techniques I am using to avoid synchronization:
> >double check idiom
> >copy on write
...
> Now, only synchronize on update, and not synchronizing on read is a problem,
> because the reader can read old or intermediate results. Some of the
> Java system library code is guilty of this practice.
For the sync on update; I mean that a method that is interested in
changing something will grab the lock, examine the value, and then maybe
change it. No sync on read means that the method that just wants to
grab the value does just that. There is no possible chance of
intermediate results as I see it because there is only one field value
being retrieved. I understand that a thread may call a getXXXX method
and find a value that is slightly outdated because slightly before this
time a _different_ thread changed it, but that is understandable.
This pattern I just described is used in my JavaBean in which the lock
locks the state (String instance used as a symbol); and there are many
properties with getters and setters. So if my reasoning that everything
is not okay as far as synchronization goes; please tell me what could go
wrong.
> Double check idiom is probably hopeless- it doesn't even work in some
> of current JVMs for single processor machine.
The hope is that it will one day once the JMM gets revised, right?
-- David Smiley
-------------------------------
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