• Did anyone read the JLS - Java Language Spec?
• Explains what compiler and JVM builder have to obey
• Java was first language that tried such a model
• Chapter 17 - Threads and Locks
• Know what is legal and what illegal
• Know where most of the speed comes from
• Know that you might not want to program in that detail

A lot of the content has been borrowed, validated, and modified from Concurrency Concepts in Java by Douglas Hawkins [1]

public class Test {
    // we all always live on the heap
    private Map<String, String> aMap;
    private int counter;
    private static final Any<Integer> = new Any<>();

    /**
     * @param a - stack only (call-by-value)
     * @param b - you don't know, reference passing on stack
     *            but the object itself?
     *            (call-by-reference)
     */
    public void foo(int a, Any<?> b) {
        int c = a++; // stack

        var d = b; // ref d on stack,
                   // but b might be anywhere

        // reference on stack, but instance?
        // when small and it does not escape on stack
        // when larger always on heap
        int[] e = new int[a];

        // reference stack, instance on heap
        List<Foo> l = new ArrayList<>();
    }
}

long shared = 0;

Thread 1
=================================================
shared = 2L;

set_hi shared, 0000 0000


set_lo shared, 0000 0002

int shared = 0;
=================================================
shared++;

local = shared;
local = local + 1;
shared = local;

getfield        #2   // Field shared:I
iconst_1
iadd
putfield        #2   // Field shared:I

0x00007f2af910f20c: mov 0xc(%rsi),%edi  ;*getfield shared
0x00007f2af910f20f: inc %edi
0x00007f2af910f211: mov %edi,0xc(%rsi)  ;*putfield shared

No out-of-thin-air reads: Each read of a variable must see a value written by a write to that variable.

This hurts big time (cutting edge performance optimizations), because every single bit is written to first (initialized) before made available. That's why, reuse might be still a good thing in Java... but then it is not immutable... darn...

shared = 20;
shared = 40;

print(shared);

• Java builds data dependency graph
• Line 4 depends on 2, but nobody on line 1
• Safe to drop line 1
• Single thread consistency

shared = 0;
for (int x : array)
{
    shared += x;
}

// Can X be 30?
x = shared * shared;

// Compiler might do that
local1 = shared;
local2 = shared;
x = local1 * local2;

// In reality, this happens...
local = shared;
x = local * local;

0x00007f7740ab2ccc: mov  0xc(%rsi),%eax ;*getfield shared
0x00007f7740ab2ccf: imul %eax,%eax      ;*imul

// done is a shared boolean
// you wrote
while (!done)
{
    // logic here
}

To some programmers, this behavior may seem "broken". However, it should be noted that this code is improperly synchronized.

Concurrency and visibility is not about modifying things at the same time (race-condition), it is all about seeing data by more than one thread. This can be operations which are seconds or even minutes apart. The outcome might still be wrong!

Data and Control Dependence

sharedX = 2;
sharedY = 3;

if (sharedX > 0)
{
    print(sharedX);
}

sharedX = 2;

if (sharedX > 0)
{
    print(sharedX);
}
sharedY = 3;

print(2);
sharedX = 2;
sharedY = 3;

==== Producer       ==== Consumer
...                 ...
sharedData = ...;   while (!sharedDone)
sharedDone = true;  {
...                     ...
                    }
                    print(sharedData);

• volatile: Write "happens before" all subsequent reads
• If Thread A writes to a volatile variable and Thread B subsequently reads the same volatile variable, then all variables visible to Thread A before writing the volatile variable, will also be visible to Thread B after it has read the volatile variable.
• If Thread A reads a volatile variable, then all variables visible to Thread A when reading the volatile variable will also be re-read from main memory.
• In other words: volatile is a performance penalty

Read-Modify-Write Problem

// what you wrote
private volatile int shared;

public void inc()
{
    shared += 1;
}

// what the machines does
private volatile int shared;

public void inc()
{
    local = shared; // read from main memory
    local = local + 1;
    shared = local; // flush to main memory
    --- fence();
}

0xc4c2fcc: mov    0xc(%rsi),%r11d
0xc4c2fd0: inc    %r11d
0xc4c2fd3: mov    %r11d,0xc(%rsi)
0xc4c2fd7: lock addl $0x0,-0x40(%rsp)  ;*putfield shared

A Java synchronized block marks a method or a block of code as synchronized. Java synchronized blocks can be used to avoid race conditions.

http://tutorials.jenkov.com/java-concurrency/synchronized.html

• Only synchronizes on objects
• Java does not synchronize threads, it synchronizes memory!

• JLS defines the happens-before relation on memory operations such as reads and writes of shared variables
• The synchronized and volatile constructs, as well as the Thread.start() and Thread.join() methods, can form happens-before relationships
• You mostly get this wrong, hence use java.util.concurrent
• Concurrent is thread-safe but not necessarily locking/blocking

private AtomicInteger atomic = new AtomicInteger(0);

public void do()
{
    atomic.getAndIncrement();
}

// under the hood
boolean applied = false;
do
{
    int value = shared.get();
    applied = shared.compareAndSet(value, value + 1);
}
while (!applied);

• Mutability is difficult
• Shared mutability is even harder
• Always design for none-shared mutability
• Immutability rules

public class MyClass
{
    private int sum;

    public synchronized void add(int i)
    {
        this.sum += i;
    }

    public int get()
    {
        return this.sum;
    }
}

• The get() is not properly done, because the cpu has no reason to go to main memory for a fresh state

• Know what the JMM is
• Know that your code is not the code that runs
• Know what optimizations are permitted
• Know what you need to make things consistent
• Know that it is difficult to do it right
• Know that you mostly should not build it yourself