Concurrency in Java: Race condition, critical section, and atomic operations

In a multithreaded program, it is possible for shared resources to be accessed concurrently.

When multiple threads access shared resources, it could create a situation where data consistency is not possible because each thread runs asynchronously.

Shared/Non shared resources

Local primitive variables

Local primitive variables are variables on the stack that hold a primitive value (of type number, string, or boolean).

Local primitive variables are stored on each thread's own stack and are never shared between threads. That means all local primitive variables are thread safe.

Locally referenced variables

Locally referenced variables are also stored on each thread's own stack and are hence not shared; however, the referenced object is stored on the shared heap.

If an object is created inside the body of a method and never escapes the method it was created in, it is thread safe.

If a locally created object is passed to other methods and objects, as long as none of these methods or objects make the passed object available to other threads, it is thread safe.

The "StringBuilder" instance in "someMethodB()" is not returned from the method, nor is it passed to any other objects that are accessible from outside of someMethodB(). Therefore, the use of the StringBuilder object is thread-safe.

Instance variables

An instance variable is a variable that is declared in a class but not in constructors, methods, or blocks.

Instance variables of an object are stored on the heap along with the object.

If two threads call a method on the same instance and this method updates an instance variable, the method is not thread-safe.

In the above example, if two threads call the "increment()" method simultaneously on the same instance of "Hello," then it leads to a race condition.

Race Condition & critical section

A race condition occurs when two or more threads access a shared resource concurrently and at least one of them tries to change it at the same time.

The portion of code where this shared resource is concurrently accessed by multiple threads is called a critical section.

Count: -23

The above code is an example of Race Condition.

Two threads, "CounterIncrementer" and "CounterDecrementer," are trying to increment and decrement the "count" variable from the "Counter" class.

Ideally, the output of this programme should be "0," because the "count" variable is being incremented and decremented "10000" times by two threads.

But as we run it, we get a different distorted value; this is because the "increment()" and "decrement()" methods are not thread safe (contain critical sections).

Data Race

A data race occurs when one thread accesses a mutable object while another thread is writing to it.

Sometimes the compiler, or CPU, executes instructions out of order to optimize performance.

This is not an issue in a single-threaded application because, irrespective of order, a complete code block will be executed by a single thread.

In a multithreaded app, we should guard such code blocks with "synchronization" so that only a single thread executes the code.

The second way of preventing "Data Racing" is to declare the variables with the "volatile" keyword.

The "volatile" keyword ensures that instructions before the volatile variable will execute before and instructions after the volatile variable will execute after.

All shared variables should either be guaranteed by a "synchronised" keyword or declared "volatile".

Atomic operations

Atomic means the operation completes without any possibility for something to happen in between.

Atomicity is an important property of multithreaded operations. Since they are indivisible, there is no way for a thread to slip through an atomic operation concurrently performed by another one.

An operation's atomicity ensures that it will complete as expected without the need for "synchronization". If operations are not atomic, a value can be changed by one thread without another thread's knowledge.

1) All referenced operations are atomic:

2) All "getters" and "setters" are atomic:

3) All assignments to primitive type except "long" and "double" are atomic:

While assignment to primitive is atomic, "increment (++)" and "decrement (--)" is not.

4) Both "long" and "double" are 64 bits and may be assigned values in two operations; hence, assignment to primitive "long" and "double" is not an atomic operation.

However, the use of the "volatile" keyword in front of a "long" or "double" primitive variable can make the assignment a single hardware operation and hence atomic.

5) Classes in the java.util.concurrent.atomic package are also atomic.