[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()
   {
     i=5
     synchronized(SomeLook){}
   }
   void print()
      synchronized(SomeOtherLook){}
      print(i) //might read 4??

now
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
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemthreadingthreadclassmemorybarriertopic.asp

- Kasper