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

Jason T. Greene jason.greene at redhat.com
Wed Jan 21 15:12:26 EST 2009

Doug Lea wrote:
> 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.

I find this perspective more convincing. The general problem with clever 
abstractions is that by hiding the true underlying mechanisms, they 
sometimes limit your capabilities or make the natural solution harder to 

Jason T. Greene
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list