> 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 depends on the values you are reading or writing. doubles and longs
aren't written atomically (necessarily) (see section 17.4 of the JLS).
If a read to such a variable is not synchronized, even if a write is, it
is possible to see the first 32 bits from one value written to it, and the
second from another. That would probably qualify as an intermediate
value.
If you can stand seeing out of date values, then you *might* not have to
synchronize read accesses otherwise, but there are a *lot* of gotchas, so
be careful.
>
> > 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?
Double check should be fixed when volatile is revised to include "cannot
reorder reads and writes past me". You will then need to use volatile
variables as the "check" variables. For a lengthy discussion, see
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Jeremy
-------------------------------
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