synchronization with respect to the memory model
Hi
Can anyone give paste me a link (other than to the JLS itself) that describes the meaning of synchronization with respect to the memory model rather than simply as a means of mutual exclusion?
You read that without synchronization different threads can have inconsistent views of what should be the same data. The link below talks of this issue but says 'the causes of memory consistency errors are complex and beyond the scope of this tutorial.'
http://java.sun.com/docs/books/tutorial/essential/concurrency/memconsist.html
Many thanks
Bruce
[585 byte] By [
bgika] at [2007-10-3 5:19:09]
the simplest case is caching - imagine one variable (adress in memory) is accessed by various threads, the CPU caches the values stored at this adress in memory lets say in a register - so how should the CPU know when to write-back the result to cache/main-memory.
With synchronization you more or less also force a flush/readback of the accessed memory.
lg Clemens
by the way - since Java-5 the "volatile"-keyword does what it promises, if a thread accesses such a variable it takes care no caching disturbs your results.
Hi linuxhippyAppreciate the reply.Is there any way of knowing which values might be cached in a local register and which won't be, or can we assume that any value can be cached? thanks
bgika at 2007-7-14 23:26:03 >
Hi again,
I found this in an article, its a better explanation of what i told you and whats the problem is:
http://www.informit.com/guides/content.asp?g=java&seqNum=248&rl=1
That means any value (primitive or reference) can be cached of course.
Thats basically what the "voaltile" keyword is there, it tells the JVM/CPU to not allow those kind of optimizations onto them. So set any variable what you access from different threads without a synchronized block volatile, e.g. public static volatile int m = 0;
Variables accesses within a synchronized block are automatically done this way.
The volatile-keyword wasn't implemented the right way prior java-5, so if you need compatibility with java-1.4 or lower you'll need to synchronize the variable access which adds overhead not really nescesarry.
Final variables don't need to be set volatile or synchronize'd the JVM will take care for them.
The article mainly mentions the java.util.concurrent classes but you can safely use volatile on primiteves and references, you'll safe the aditional object overhead.
lg Clemens
> Hi linuxhippy
> Appreciate the reply.
>
> Is there any way of knowing which values might be
> cached in a local register and which won't be, or can
> we assume that any value can be cached?
You have to assume that each thread can have its own copy of any non-volatile variable.
jverda at 2007-7-14 23:26:03 >
> Variables accesses within a synchronized block are
> automatically done this way.
No, that's not the case.
Variables must be read from main memory when first used in a sync block, and written back out to main mem upon exiting, but within the sync block, the thread can use local copies off any non-volatile variable.
> The article mainly mentions the java.util.concurrent
> classes but you can safely use volatile on primiteves
Might want to double check that. I thought that double and long were still non-atomic, even when volatile, though I might be wrong here, or it might have tightened up with 5.0.
jverda at 2007-7-14 23:26:03 >
> Variables must be read from main memory when first
> used in a sync block, and written back out to main
> mem upon exiting, but within the sync block, the
> thread can use local copies off any non-volatile
> variable.
Yes, and that was what I tried to tell. If you enter the block its read, if you leave its written.
I never said that it is always written back / read from main memory.
> Might want to double check that. I thought
> that double and long were still non-atomic, even when
> volatile, though I might be wrong here, or it might
> have tightened up with 5.0.
As far as I know since 5.0 long and double are also atomic, but of course not read/write operations to them (e.g. variable++).
lg Clemens
BruceThe best and only authoritative reference is chapter 17 of the JLS: http://java.sun.com/docs/books/jls/third_edition/html/memory.html
ejpa at 2007-7-14 23:26:03 >
There are many articles and a few book chapters or parts thereof that deal with the new memory model, and of course some key websites. The primary website is:
http://www.cs.umd.edu/~pugh/java/memoryModel/
Brian Goetz has written a number of articles on IBM's DeveloperWorks, and of course this is covered in great depth in "Java Concurrency in Practice" by Goetz et al.
I also covered it in the threading chapter of "The Java Programming Language, 4th edition". :)
A few key points:
- access to volatile long/double has always been atomic (old JMM and Java 5 JMM), but remeber that access means a simple read, or a simple write, something like ++ is not atomic because it is a read followed by a write
- don't think of this in terms of "caches" - that will lead to the wrong reasoning. It isn't about flushing caches or writing to main memory (that was the old conceptual model that just gets people into trouble because they keep trying to reconcile it with how the hardware chaching works). The new memory model is all about establishing happens-before relations ships between writes and reads of a variable, so that the value allowed to be returned from a read is the most recent value that was written.
- the definitive source for this is actuall the JSR-133 specification. Chapter 17 of the JLS 3e is based on that spec but doesn't contain the full details. (But you are better off reading Ch17 than the proper spec :) )
> Can anyone give paste me a link (other than to the
> JLS itself) that describes the meaning of
> synchronization with respect to the memory model
> rather than simply as a means of mutual exclusion?
To answer this specific question:
"The release of a monitor lock happens-before any subsequent acquisition of that same monitor lock."
But I bet that didn't help much :) The key is the transitivity property of happens-before and that within a thread any action that comes before another action in program order (ie the way you write the source code) also happens-before it. In more direct terms any values written to variables prior to the release of the monitor lock on object O, will be visible to another thread that subsequently acquires the lock of O.
It will make more sense when you consult some of the references I gave. Honest! :)
> There are many articles and a few book chapters or
> parts thereof that deal with the new memory model,
> and of course some key websites. The primary website
> is:
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/
>
> Brian Goetz has written a number of articles on IBM's
> DeveloperWorks, and of course this is covered in
> great depth in "Java Concurrency in Practice" by
> Goetz et al.
>
> I also covered it in the threading chapter of "The
> Java Programming Language, 4th edition". :)
>
>
> A few key points:
>
> - access to volatile long/double has always been
> atomic (old JMM and Java 5 JMM), but remeber that
> access means a simple read, or a simple write,
> something like ++ is not atomic because it is a read
> followed by a write
>
> - don't think of this in terms of "caches" - that
> will lead to the wrong reasoning. It isn't about
> flushing caches or writing to main memory (that was
> the old conceptual model that just gets people into
> trouble because they keep trying to reconcile it with
> how the hardware chaching works). The new memory
> model is all about establishing happens-before
> relations ships between writes and reads of a
> variable, so that the value allowed to be returned
> from a read is the most recent value that was
> written.
>
I was under the belief that the previous MM was writen in the way that it was in order to allow flexibility in terms of instuction/read/write reordering, caching, synch block merging and any number of other things that may occur, such that vm's on various architectures could be written efficently.
Of course it could have been that vm writers on those various architectures took advantage of the slack nature of the spec to implement all of those non-standard interpretations of the spec :). Its definately a good thing that the spec has been redefined to make it clearer exactly what a java develper should expect.
> - the definitive source for this is actuall the
> JSR-133 specification. Chapter 17 of the JLS 3e is
> based on that spec but doesn't contain the full
> details. (But you are better off reading Ch17 than
> the proper spec :) )
matfud
> I was under the belief that the previous MM was
> writen in the way that it was in order to allow
> flexibility in terms of instuction/read/write
> reordering, caching, synch block merging and any
> number of other things that may occur, such that vm's
> on various architectures could be written efficently.
Yes it was - as is the new spec. The problem with the old memory model was that it was both too strong and too weak, as discussed in Bill Pugh's paper.
The problem with the conceptual model of the old JMM, talking about local memory. main memory, and "flushing" is that people try to take it too literally and try to reason about what the memory model allows by reasoning about particular cache architectures etc - and that doesn't work.
The happens-before relationship, while initially hard to grasp, actually makes it a lot easier to reason about what is and isn't allowed.
