At 9:01 AM +0000 10/30/03, Martin Trotter wrote:
>I think that what you need is not a barrier of some sort in each thread but
>a way for a
>single updating thread to force all the other threads to look at its
>changes. Very like
>the garbage collector thread in fact. The way that the GC thread does this
>is to stop all the other threads in some way either by forcing them to
>cooperate or
>simply by getting the OS to suspend them forcibly. In either case the GC
>thread ends
>up with a view of the other threads state and the other threads are forced
>to reread
>everything from main memory on resume. The Thread.suspend and
>Thread.resume
>methods, although deprecated, are exactly what you need in these
>situations. Perhaps
>we should look at undeprecating them ?
>
>Martin Trotter
>
thread.suspend has no semantics in the memory model.
It would be difficult to assign any MM semantics to thread.resume,
since you can't identify which actions, in the resumed thread, come
after the thread is resumed.
Sylvia, I still think you are getting all worked up over something
that won't be a problem. On ia64, a load.acquire will be very fast if
the memory location is in cache. At any rate, on ia64, the only way
to get the behavior you want is with a load.acquire.
You also need to worry about things being cached in registers. You
can't have just the updating thread perform a volatile operation, and
have the threads that want to see the updates avoid doing any
volatile or synchronization operations. Unless the threads that need
to see the updates do a volatile or synchronization operation, they
can keep reloading stuff from registers, never going to main memory.
Can you give us the code you are concerned about? We can run it on
ia64 with and without volatiles, and see what the difference is.
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:52 EDT