What are the 'synchronized barriers'?

Question

Recently I was reading the page The JSR-133 Cookbook for Compiler Writers by Doug Lea regarding JSR 133: JavaTM Memory Model and Thread Specification Revision.

There I read this line:

Memory barriers are not themselves "synchronization barriers"

I've searched to find some resources about the differences between memory barriers and synchronized barriers but could not find anything good. I also can't tell if synchronized barriers have any difference in comparison of Java with other languages.

Shocking

I think that the author is drawing a distinction between a barrier involving only the processor and its memory (a low-level implementation matter) and a barrier that involves the Java memory model, specifically inter-thread operations. A memory barrier alone might fail to copy a volatile variable during a thread switch on a single processor, for instance. – Limp

Note the beginning: "This is an unofficial guide to implementing the new Java Memory Model (JMM)" So the guide is intended for people implementing a JVM, not for people using the JVM. – Hanger

Answer 1

First of all, as @markspace points out, the document you are looking at is not intended to as a document for Java programmers trying to understand how to write threaded code correctly.

"This is an unofficial guide to implementing the new Java Memory Model (JMM)"

So if you are reading it for that purpose, you are likely to confuse yourself unnecessarily. You should instead be either using Java's higher level concurrency mechanisms (best!), or reading and understanding the JMM spec.

---

The synchronization barrier (not a "synchronized barrier") is (I believe) referring to terminology the Java Memory Model.

JLS 17.4.4 defines a synchronizes-with relation between various actions. This relation implies a synchronization between two threads:

The source of a synchronizes-with edge is called a release, and the destination is called an acquire.

I am not sure about this (because the Cookbook document does not elaborate), but I think that "a synchronization barrier" in the Cookbook is referring to a physical implementation of a synchronizes-with edge ... whatever that might be.

So what the document is saying here is that the memory barriers it refers to are not the same thing as the mechanisms that implement locks and so on. Which is kind of obvious really.

Lorenelorens

Mostly this is how I read it as well. The low level "memory barrier" as implemented by a CPU instruction set is not a one-to-one mapping of all the things a JVM might need to do to implement "synchronization" correctly. It's not a fire-and-forget situation, an implementor has to be certain they've implemented the spec correctly. – Hanger

The thing about official/not official documentation ... I know that this is not an official doc but it is written by Doug Lea.I don't think that a concurrency master like him, who have read so many classes and libraries for java.concurrency package (e.g. ReentrantLock) would write anything wrong about a topic related to concurrency – Shocking

I don't see how official vs unofficial is relevant to what I said. The point we are making is related to the purpose of the document, not its status. Notice the word that I highlighted in my answer. Also, nowhere have I said that anything that Doug Lea has said is wrong. And if you think I implied it then you are misconstruing what I wrote. – Lorenelorens

Answer 2

Look at the name... ... for compiler writers, this should make it clear. Doug Lea, among other people, have build a draft document (a starting point) that compiler writers can start with.

The problem is that a JVM can go beyond, or ignore totally that document, as long as that would be legal. For example:

public void go() {
    
     synchronized(this) {
        int x = 1;
     }

     synchronized(this) {
        int y = 2;
     }

}

That document says that there will be "memory barriers" inserted, basically x = 1 and y = 2 can not move outside the synchronized block. In practice, a JVM will do:

   public void go() {
    
     synchronized(this) {
        int x = 1;
        int y = 2;
     }

}

which is an optimization called "lock coarsening", without any problems. So the document is really just a starting point to define some basic rules.

The "synchronized barriers" refers to this chapter; and it defines the rules for correctly "synchronizing" access to shared variables for proper memory effects to have effect.

Pachydermatous