Thread-safe access to shared data
Last updated
Last updated
Imagine if you could lock a shared object while it was being accessed by a thread; you’d be able to prevent other threads from modifying it. This is exactly what Java does to make its data thread safe. Making your applications thread safe means securing your shared data so that it stores correct data, even when it’s accessed by multiple threads. Thread safety isn’t about safe threads—it’s about safeguarding your shared data that might be accessible to multiple threads. A thread-safe class stores correct data without requiring calling classes to guard it.
You can lock objects by defining synchronized methods and synchronized statements. Java implements synchronization by using monitors, covered in the next quick warm- up section.
Every Java object is associated with a monitor, which can be locked or unlocked by a thread. At a time, only one thread can hold lock on a monitor and is referred to as the monitor owner. Owning the monitor is also referred to as acquiring the monitor. If another thread wants to acquire the monitor of that object, it must wait for it to be released.
When the keyword synchronized is added to a method, only one thread can execute it at a time. To execute a synchronized method, a thread must acquire the monitor of the object on which the method is called. When the monitor of an object is locked, no other thread can execute any synchronized method on that object. When acquired, a thread can release the lock on the monitor if
It has completed its execution.
It needs to wait for another operation to complete.
For the first case, it releases the lock and exits. For the latter case, it enters a waiting set of threads that are waiting to acquire the monitor again. Threads enter the waiting set due to an execution of wait. They can reacquire the monitor when notify- All() or notify() is called.
Figure below shows how a thread might have to wait to hold a lock on a monitor. Only one thread can own the monitor of an object, and a thread might release the monitor and enter a waiting state.
A thread must own a monitor before it can execute synchronized code. Only the monitor owner can execute the synchronized code.
With an understanding of how objects and their monitors, threads, and execution of synchronized code work together, let’s modify the code used in section Thread interference so that threads working with shared data don’t interleave.
Synchronized methods are defined by prefixing the definition of a method with the key- word synchronized. You can define both instance and static methods as synchronized methods. The methods, which modify the state of instance or static variables, should be defined as synchronized methods. This prevents multiple threads from modifying the shared data in a manner that leads to incorrect values.
When a thread invokes a synchronized method, it automatically locks the monitor. If the method is an instance method, the thread locks the monitor associated with the instance on which it’s invoked (referred to as this within the method). For static methods, the thread locks the monitor associated with the Class object, thereby representing the class in which the method is defined. These locks are released once execution of the synchronized method completes, with or without an exception.
In the following listing, let’s modify the definition of class Book by defining its meth- ods newSale() and returnBook() as synchronized methods. The methods that belong to the data being protected are defined as synchronized.
Figure below shows how threads task2, task1, and task3 might acquire a lock on the monitor of object book defined in the main method of class ShoppingCart. As you see, a thread can’t execute synchronized methods newSale() and returnBook() on book without acquiring a lock on its monitor. So each thread has exclusive access to book to modify its state, resulting in a correct book state at the completion of main.
What happens if, instead of defining methods newSale() and returnBook() as synchronized methods (see listing 1), you define the run() methods in the threads OnlineBuy and OnlineReturn as synchronized methods? Will this modification protect the data of shared object book in ShoppingCart? Let’s answer this question in the next “Twist in the Tale” exercise. Take a closer look; apart from the mentioned modification, I’ve also modified some other bits of code.
Purpose: To synchronize the right methods to protect your shared data
Answer: c
Explanation: Because the methods newSale() and returnBook() aren’t defined as synchronized methods, multiple threads can access these methods concurrently, posing a risk of thread interference that fails to protect the data of object book, defined on line 3. Defining the run() methods as synchronized doesn’t help to protect the data of object book. It restricts execution of run to a single thread; it doesn’t restrict modification of an instance of Book to a single thread. To protect your shared data, you should add the synchronized keyword to the methods that directly manipulate your shared data.
As stated before, when a thread acquires a lock on the object monitor, no other thread can execute any other synchronized method on the object until the lock is released. This could become inefficient if your class defined synchronized methods that manipulate different sets of unrelated data. To do so, you might mark a block of statements with the keyword synchronized, as covered in the next section.
To execute synchronized statements, a thread must acquire a lock on an object moni- tor. For an instance method, it might not acquire a lock on the instance itself. You can specify any object on which a thread must acquire the monitor lock before it can exe- cute the synchronized statements.
In the previous example for class Book, let’s remove the keyword synchronized from the definition of method newSale() and define synchronized statements in it:
A thread releases the lock on the object monitor once it exits the synchronized statement block due to successful completion or an exception. If you’re trying to modify your shared data using synchronized statements, ensure that the data items are mutually exclusive. As shown in the preceding example, the object references objSale and objPos refer to different objects.
3)
Synchronized blocks in Java are marked with the synchronized
keyword. A synchronized block in Java is synchronized on some object. All synchronized blocks synchronized on the same object can only have one thread executing inside them at the same time. All other threads attempting to enter the synchronized block are blocked until the thread inside the synchronized block exits the block.
The synchronized
keyword can be used to mark four different types of blocks:
Instance methods
Static methods
Code blocks inside instance methods
Code blocks inside static methods
These blocks are synchronized on different objects. Which type of synchronized block you need depends on the concrete situation.
Here is a synchronized instance method:
Notice the use of the synchronized
keyword in the method declaration. This tells Java that the method is synchronized.
A synchronized instance method in Java is synchronized on the instance (object) owning the method. Thus, each instance has its synchronized methods synchronized on a different object: the owning instance. Only one thread can execute inside a synchronized instance method. If more than one instance exist, then one thread at a time can execute inside a synchronized instance method per instance. One thread per instance.
Static methods are marked as synchronized just like instance methods using the synchronized
keyword. Here is a Java synchronized static method example:
Also here the synchronized
keyword tells Java that the method is synchronized.
Synchronized static methods are synchronized on the class object of the class the synchronized static method belongs to. Since only one class object exists in the Java VM per class, only one thread can execute inside a static synchronized method in the same class.
If the static synchronized methods are located in different classes, then one thread can execute inside the static synchronized methods of each class. One thread per class regardless of which static synchronized method it calls.
You do not have to synchronize a whole method. Sometimes it is preferable to synchronize only part of a method. Java synchronized blocks inside methods makes this possible.
Here is a synchronized block of Java code inside an unsynchronized Java method:
This example uses the Java synchronized block construct to mark a block of code as synchronized. This code will now execute as if it was a synchronized method.
Notice how the Java synchronized block construct takes an object in parentheses. In the example "this" is used, which is the instance the add method is called on. The object taken in the parentheses by the synchronized construct is called a monitor object. The code is said to be synchronized on the monitor object. A synchronized instance method uses the object it belongs to as monitor object.
Only one thread can execute inside a Java code block synchronized on the same monitor object.
The following two examples are both synchronized on the instance they are called on. They are therefore equivalent with respect to synchronization:
Thus only a single thread can execute inside either of the two synchronized blocks in this example.
Had the second synchronized block been synchronized on a different object than this
, then one thread at a time had been able to execute inside each method.
Here are the same two examples as static methods. These methods are synchronized on the class object of the class the methods belong to:
Only one thread can execute inside any of these two methods at the same time.
Had the second synchronized block been synchronized on a different object than MyClass.class
, then one thread could execute inside each method at the same time.
Here is an example that starts 2 threads and have both of them call the add method on the same instance of Counter. Only one thread at a time will be able to call the add method on the same instance, because the method is synchronized on the instance it belongs to.
Two threads are created. The same Counter
instance is passed to both of them in their constructor. The Counter.add()
method is synchronized on the instance, because the add method is an instance method, and marked as synchronized. Therefore only one of the threads can call the add() method at a time. The other thread will wait until the first thread leaves the add() method, before it can execute the method itself.
If the two threads had referenced two separate Counter
instances, there would have been no problems calling the add() methods simultaneously. The calls would have been to different objects, so the methods called would also be synchronized on different objects (the object owning the method). Therefore the calls would not block. Here is how that could look:
Notice how the two threads, threadA and threadB, no longer reference the same counter instance. The add
method of counterA
and counterB
are synchronized on their two owning instances. Calling add()
oncounterA
will thus not block a call to add()
on counterB
.