RE: JavaMemoryModel: More ordering constraints does not imply more reliable software

From: Miles Sabin (
Date: Tue Jul 10 2001 - 16:15:29 EDT

Bill Pugh wrote,
> For example, I suspect that having a readMemoryBarrier() function
> call available would be a horrible mistake. 99% of all programmers
> who tried to use it would use it incorrectly. I'm not sure I could
> use it correctly (what is a "read" memory barrier, as opposed to a
> "write" memory barrier? Does is prevent reordering of previous
> reads with following reads, but allow arbitrary reordering of
> writes?)

Hmm ... you've lost me.

Weren't earlier recommending using dummy reads/writes as read/write
barriers, as a justification for volatile accesses *not* being full
two way barriers? Surely any argument that {read,write}Barrier() will
be error prone would apply with at least the same (if not greater)
force against dummy reads/writes?

I don't think you can have it both ways. Either dummy reads/writes are
a viable and comprehensible technique, in which case
{read,write}Barrier() would be even more so; or {read,write}Barrier()
is not a viable and comprehensible technique, in which case dummy
reads/writes aren't either (and maybe volatile accesses should be
full two way barriers).



Miles Sabin                                     InterX
Internet Systems Architect                      27 Great West Road
+44 (0)20 8817 4030                             Middx, TW8 9AS, UK                     

------------------------------- JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT