Sarita Adve wrote,
> I would like to point out that based on Bill's proposal so far,
> volatiles cannot be treated as one-way barriers (for non-volatile
> accesses), leave alone as two-way barriers.
<snip/>
> Instead of thinking about volatiles as barriers for normal (non-
> volatile) accesses, think of them as accesses used for communication
> of normal locations between two threads. A volatile write is a
> sender of previous normal values of its processor and a volatile
> read is a receiver for subsequent normal accesses of its processor.
>
> Some codes may want to use a read volatile to send normal values and
> a write to receive values - this is what people have been calling
> two-way barriers - but viewed in this way, it isn't very intuitive
> for a write to recieve and read to send information.
Thanks for this clarification. Do we have some terminology other than
'barrier' (which has certainly been confusing me here)? Clearly the
semantics that have been described set up a temporal boundary with
some actions on one side and some on the other. But as you've pointed
out, this isn't a memory barrier in the traditional sense.
Also, on reflection, and after taking a close look at Bills rewrite
of the optimistic readers example, I'm no longer quite so sure that
a utility class would be of much value. At best it would encapsulate
a volatile, a pre-boundary sending write and a post-boundary receiving
read. And that doesn't really make the optimistic readers code much
more comprehensible than it is with exposed dummy reads and writes.
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