[concurrency-interest] memory barriers

Kasper Nielsen news@kav.dk
Thu, 29 Jan 2004 12:53:04 +0100

Joseph Bowbeer wrote:
> Kasper Nielsen asks:
>>print(foo.i) might write 4?
> In your example, the same thread that constructs foo also calls
> helper.print(foo), so the answer will always be 5.  Inside a single thread,
> program order rules.

oops I meant something like (too early in the morning)

class foo
   int i=4
   void fooMethod()
   void print()
      print(i) //might read 4??

1. some thread calls fooMethod()
2. some other threads calls print() (but after fooMethod() has returned)

The question was really if the statement
Changes to fields made by one thread are guaranteed to be visible to 
other threads only under the following conditions:
A writing thread releases a synchronization lock and a reading thread
subsequently acquires that _same_ synchronization lock.
do it really need to be the _same_ synchronization lock?

> The JMM spec is unclear about memory barriers so they can removed when it is
> determined they are not needed.  (In addition, memory barriers per se may
> not exist on some platforms.)
They have something similar on the .NET platform

- Kasper