Java Locks and Atomicity
Java Locks and Atomicity
Only single, discrete language operations are ever going to be atomic.
Join the DZone community and get the full member experience.Join For Free
It's important not to confuse people by using words that are imprecise or ambiguous. This annoys many experts because this world is confusing enough. I will point my fingers to the "misuse" of the word atomic. I have to be careful here because I had the idea for this post when I was reading the bible of concurrency: Java Concurrency in Practice. However, in this book, just for instance, the word atomic is used in a way, which can confuse people that spent five years of their career building transactional database systems. In short:
In Java, only single, discrete language operations are ever going to be atomic. There is no such concept in Java that inherently creates atomicity.
Assigning a value to a variable is an atomic operation in Java. Calling a method (the call itself) or creating an object may be atomic, but the atomic data types like
AtomicInteger provide atomic actions. There are more examples. However, if one tries to explain the notion of Java locks by giving the impression they make compound language operations atomic, then this is not 100 percent correct. Locks can make sure that the sequence of language operations are going to be performed in isolation to other concurrent threads working with that same resource. That's exactly what locks like
ReentrantReadWriteLock add to the language features.
Locks cannot garantee atomicity, which I explained by providing broken and working examples in one of my other posts. In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of operations intended to guarantee validity even in the event of errors, power failures, etc. Atomicity, in particular, guarantees that each compound action is treated as a single "unit of work," which either succeeds completely or fails completely. If any of the compound actions constituting a unit of work fails to complete, the entire unit of work fails and the data is left unchanged (Wikipedia). As I have shown in my post, Java cannot guarantee that without adding extra code, like exception handling, to intrinsic and explicit locks.
Isolation ensures that concurrent execution of compound actions leaves the system in the same state that would have been obtained if the compound actions were executed sequentially. This is exactly the safety feature that locks add to concurrent Java programs.
Java locks add the isolation feature to compound actions.
If you want to add atomicity to any sequence of compound actions, then this will only be possible by doing extra work, like proper exception handling, to recover the system state in case of an unexpected event. This actually requires more than only applying locks.
Opinions expressed by DZone contributors are their own.