[concurrency-interest] memory barriers

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


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.

Btw, the code sample also illustrates the dangerous practice of "releasing"
the object reference before it has been fully constructed.

If one thread constructs foo and a different thread somehow calls
fooHelper.print(foo) before foo is fully constructed then print may write 4.


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.)



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


Hi,

I was wondering if there exist some documents about exactly when an
memory barrier is performed.

For example by reading http://gee.cs.oswego.edu/dl/cpj/jmm.html
---
  A writing thread releases a synchronization lock and a reading thread
subsequently acquires that _same_ synchronization lock.
---
One get the impression that the following will not work

class foo
   int i=4
   fooHelper helper
   foo()
   {
     i=5
     synchronized(this){}
     helper.print()
   }

class fooHelper
   print(foo)
      synchronized(this)
      print(foo.i) //might read 4??


One really neat feature would be if ThreadGroup (and Thread) had a
(blocking) memorybarrier() method.
so when you did baseThreadGroup.memorybarrier you could rest assure that
all threads had fresh data.

- Kasper