After an application is deployed to production, developers should lock down its underlying infrastructure to prevent accidental changes. Some of the common accidents that can affect the availability of an application in production are: moving, renaming, or deleting the resource crucial to the function of the application. You can use locks that prevent anyone from performing a forbidden action to avoid such mishaps.
Creating Locks
Almost every resource in Azure supports locks, so you will find the lock option in the settings section of nearly all resources in the portal. For example, the following screenshot illustrates locks on resource groups:
Lock Striping in Java
There are dozens of decent lock-free hashtable implementations. Usually, those data structures, instead of using plain locks, are using CAS-based operations to be lock-free. with this narrative, it might sound I’m gonna use this post to build an argument for lock-free data structures. that’s not the case, quite surprisingly. on the contrary, here we’re going to talk about plain old locks.
Now that everybody’s onboard, let’s implement a concurrent version of Map with this simple contract:
Java Locks and Atomicity
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 ReentrantLock and ReentrantReadWriteLock add to the language features.