Synchronization is lot more than Mutual Exclusion

In multiprocessor systems, processors generally have one or more layers of memory cache. Cache speeds up speed of accessing the data as data is closer to memory.

It also reduces traffic on the shared memory bus as many memory operations can be done using cache only.

Using cache effects the concurrent execution of program.

At the processor level, a memory model defines necessary and sufficient conditions for knowing that writes to memory by other processors are visible to the current processor, and writes by the current processor are visible to other processors.

Types of memory model:

  1.     Strong  memory model: For a given memory location, all processors see the same value

  2.     Weaker memory model: special instructions, called memory barriers, are required to flush or invalidate the local processor cache in order to see writes made by other processors or make writes by this processor visible to others.

These memory barriers are usually performed when lock and unlock actions are taken; they are invisible to programmers in a high level language.

Recent trends in processor design have encouraged weaker memory models, because the relaxations they make for cache consistency allow for greater scalability across multiple processors and larger amounts of memory.

The issue of when a write becomes visible to another thread is compounded by the compiler's reordering of code.

A simple example of this can be seen in the following code:

Class Reordering {

  int x = 0, y = 0;

  public void writer() {

    x = 1;

    y = 2;

  }

  public void reader() {

    int r1 = y;

    int r2 = x;

  }

}

Let's say that this code is executed in two threads concurrently, and the read of y sees the value 2. Because this write came after the write to x, the programmer might assume that the read of x must see the value 1. However, the writes may have been reordered. If this takes place, then the write to y could happen, the reads of both variables could follow, and then the write to x could take place. The result would be that r1 has the value 2, but r2 has the value 0.

The Java Memory Model describes what behaviors are legal in multithreaded code, and how threads may interact through memory. It describes the relationship between variables in a program and the low-level details of storing and retrieving them to and from memory or registers in a real computer system. It does this in a way that can be implemented correctly using a wide variety of hardware and a wide variety of compiler optimizations.

What is meant by reordering?

There are a number of cases in which accesses to program variables (object instance fields, class static fields, and array elements) may appear to execute in a different order than was specified by the program. The compiler is free to take liberties with the ordering of instructions in the name of optimization. Processors may execute instructions out of order under certain circumstances. Data may be moved between registers, processor caches, and main memory in different order than specified by the program.

For example, if a thread writes to field a and then to field b, and the value of b does not depend on the value of a, then the compiler is free to reorder these operations, and the cache is free to flush b to main memory before a. There are a number of potential sources of reordering, such as the compiler, the JIT, and the cache.

What do you mean by incorrectly synchronized?

Incorrectly synchronized code can mean different things to different people. When we talk about incorrectly synchronized code in the context of the Java Memory Model, we mean any code where

1.     there is a write of a variable by one thread,

2.     there is a read of the same variable by another thread and

3.     the write and read are not ordered by synchronization

When these rules are violated, we say we have a data race on that variable. A program with a data race is an incorrectly synchronized program.

What does synchronization do?

Synchronization has several aspects.

1.     Mutual exclusion: only one thread can hold a monitor at once, so synchronizing on a monitor means that once one thread enters a synchronized block protected by a monitor, no other thread can enter a block protected by that monitor until the first thread exits the synchronized block.

2.      Synchronization ensures that memory writes by a thread before or during a synchronized block are made visible in a predictable manner to other threads which synchronize on the same monitor.

		Exit Synchronized block --> Release Moniter -> Flush cache to main memory.                                                           Write by this thread is visible to all other threads Before enter synchronnized block  -> Acquire monitor --> Invalidate local processor cache so memory will be reloaded from main memory. (Now this thread can see changes by other thread)

The new memory model semantics create a partial ordering on memory operations.

When one action happens before another, the first is guaranteed to be ordered before and visible to the second. The rules of this ordering are as follows:

• Each action in a thread happens before every action in that thread that comes later in the program's order.
• An unlock on a monitor happens before every subsequent lock on that same monitor.
• A write to a volatile field happens before every subsequent read of that same volatile.
• A call to start() on a thread happens before any actions in the started thread.
• All actions in a thread happen before any other thread successfully returns from a join() on that thread.

synchronized (new Object()) {}

Will not work because compiler remove this block.

Reason: compiler knows that no other thread can synchronized on the same object/monitor.

Writing to a volatile field has the same memory effect as a monitor release, and reading from a volatile field has the same memory effect as a monitor acquire.