[concurrency-interest] [Javamemorymodel-discussion] Fences.keepAlive

Doug Lea dl at cs.oswego.edu
Wed Jan 21 13:30:32 EST 2009


Joe Bowbeer wrote:
> 
> It's hard for me to mesh fences with the JMM.  In the context of JMM, fences
> seem like magic.  (Whereas in the magical world of a DEC Alpha, fences impose
> reality.)
> 

Although from a different perspective, it is almost the
opposite.  Memory consistency is all about the relations
among memory accesses, not the accesses themselves. If
people somehow liked programming the interstices across
accesses (which is what fences do), it would probably be
easier to specify a fairly simple memory model of sorts that
described effects.  But no one likes to program in this way,
and even if they did, it would be much harder to verify
correct usage. So instead the JMM associates relations with
sets of accesses of variables tagged as volatile etc. Which
enters the messy territory of how mixtures of volatiles,
non-volatile, and final accesses interrelate. If you instead
program directly use Fence API, you don't have to pay
attention to this part much, but on penalty of having to
program in a very unnatural way -- a style that you would
only tolerate in a small part of your program for the sake of
enforcing an ordering relation that is not otherwise obtainable;
i.e., because the available means of expressing them are either
too weak to too strong.

In other words, the Fences API methods are just as removed from
hardware as volatile specs are. They feel closer
because HW folks have no sympathy about programmability, so
usually only provide instruction sets supporting
interstice-programming (fences), on top of a set
of base ordering guarantees, rather than tagged variable
access, so the mapping is easier.

(*) Footnote/disclaimer: However, there is one access-based,
not relation-based property of volatiles -- access is
guaranteed atomic even for longs and doubles, unlike the
case for non-volatiles.

> More to the point: Are there Java code transformations (e.g., injections)
> that could be used to illustrate what they really do in terms of Java code?

No, only the opposite.

> 
> Are fences actually cheap to implement on all platforms?  Won't there be some
> platforms where they are more expensive than current alternatives? (If not,
> why wasn't the JMM spec'd in terms of fences?)

(See above :-)

-Doug



More information about the Concurrency-interest mailing list