At 9:10 AM -0500 7/19/01, Sarita Adve wrote:
>So if an SMT allows a thread to read data of another thread early from a
>write buffer on the same processor, it is really doing option (3).
>
>As an aside, an SMT does not necessarily mean that *all* structures will be
>shared. It is possible to conceive of an SMT with per-thread write buffers
>(either in a physical or virtual sense). That is, it is possible to get
>benefits of SMT on a system that wants to retain option (2) but not (3).
Yes, but I find it hard to imagine that chip architectures would
expend transistors to duplicate write buffers.
Does anyone know if any of the planned SMT architectures (e.g., the
Alpha EV8, never to see the light of day) duplicated write buffers?
So I am worried over mandating that Java volatiles have write
atomicity. I think it is quite possible that within 5-10 years there
will be architectures that don't support it.
What are the arguments in favor of volatile write atomicity? I think
there are two issues:
* Can we devise a memory model that doesn't enforce volatile write
atomicity (that also handles all of the other issues we are dealing
with)?
* Are there any useful or intuitive programming idioms that will
break if volatile writes are not atomic?
Let's put aside the first question for the moment. What breaks if
volatile writes are not atomic?
Bill
-------------------------------
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