[concurrency-interest] memory barriers

Joseph Bowbeer jozart@blarg.net
Thu, 29 Jan 2004 04:43:16 -0800


Kasper Nielsen writes:

> Does it really need to be the _same_ synchronization lock?

Yup.  (Depending on how optimal the JVM is...)


> They have something similar [MemoryBarrier] on the .NET platform

Interesting.  If JMM achieves its goals then correctly synchronized Java
code will not only be more readable but will also soundly outperform .NET
code on multiprocessor Itaniums.


----- Original Message ----- 
From: "Kasper Nielsen" <news@kav.dk>
To: <concurrency-interest@altair.cs.oswego.edu>
Sent: Thursday, January 29, 2004 3:53 AM
Subject: Re: [concurrency-interest] memory barriers


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