David Holmes wrote:
> Although I've been an advocate of the "no word tearing" rule I'm surprised
> that there has been no comment from the VM folk concerning the cost of
> avoiding word tearing. If subword accesses are not atomic on a given
> architecture then either synchronization of array accesses must be used, or
> else subword variables must actually be aligned on word boundaries. The
> former seems excessively expensive while the latter would not be appreciated
> by people trying to constrain memory usage. Is it simply that subword
> accesses are atomic on the architectures most cared about ?
>
> David Holmes
>
> -------------------------------
> JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
>
I have no idea what the hardware does. I assume
(without knowledge, very dangerous) that Sparc
Does The Right Thing; if I do subword writes they
will be atomic. Intel makes no promises in any
case, so what else is new?
A few interesting optimizations are explicitly
disallowed. HotSpot packs fields, so subword
operations can be (but are not now) profitably
coalesced into word operations. This might change
by 1.4.1, unless it's disallowed.
I'm annoyed by this rule, but lack of it seems
untenable: if I have a 'race condition' in any
part of an object (thread A writes field A, thread
B writes field B) I might be subject to word
tearing and lose one of the writes. How can any
large program reasonably defend against such
behavior? Do I require shared objects have
exactly one writeable field?
Thus I assume this rule must come to pass, and
so I forgo coalescing of writes. If you can show
how word tearing can be made less painful, I'd
love to have write-coalescing back.
Cliff
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:37 EDT