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).
Cheers,
Miles
-- Miles Sabin InterX Internet Systems Architect 27 Great West Road +44 (0)20 8817 4030 Middx, TW8 9AS, UK msabin@interx.com http://www.interx.com/------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT