Of course there are no garuntees, but on a SMP or NUMA architecutre, the
write buffers are only so deep, eventually, the write will be reflected in
main memory (that is, it is commited). I think this would even be the case
on IBM's SCOMA scheme. In fact, most shared memory architectures will
eventually make writes viewable (that is, in a finite, good enough, time)
even if they can't make any garuntees about the order.
When dealing with optimizations, you really want to know where
synchronization "can" occur in implementation of an abstract method. I
need to be able to restrict some abstract methods from being able to
have implentations that use synchronization (that is, caller transparent
synchronization cannot occur), then the set of optimization that I can do
at a high level become larger. This is where transparent caching that does
not use synchronization but is still safe with respect to reads comes in
handy.
Sean
On Mon, 25 Oct 1999, Bill Pugh wrote:
> >
> >Egats, I understand the current JMM has a problem with immutable objects,
> >"IF" immutable objects were garunteed to be immutable, this would work. I
> >believe (hope) a new memory model will fix this. Otherwise I believe that
> >synchronization is not nescessarily nescessary for a "correct" hashtable
> >with limited functionality.
> >
>
> For your code, these is also the factor that there isn't anything
> that requires that a thread _ever_ see any of the writes by any other
> thread.
>
> In this case, that is valid. But it would be nice to see some of the
> writes by other threads, even if we don't make any guarantees about
> the promptness of that. The only way to do that is through
> synchronization or a volatile field.
>
> 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:21 EDT