In the previous article, we have talked about how JMM abstractions map to hardware. This time, we will look into threading. If you wish to have a better idea of what things like inflated monitors, biased locking, thread parking or lock contention are, this post is for you. Like the last time, it will contain two sections: a general overview of what should be happening, and then some hands-on OpenJDK fun.

The Theoretical Stuff

Most of the time, whenever we have some concurrently executing code, we also have the need to somehow communicate between them. There are many forms this communication may take, we will only concentrate on some of those.

• Visibility: assuming that the concurrently executing processes (not in the sense of a UNIX process, mind you) have some shared state, we need the processes to see each other’s changes to that state. This was discussed the last time in sufficient detail
• Atomicity: we might need to change the state atomically, i.e. in such a way that no other process may jump in the middle of our operation, and screw things up
• Mutual Exclusion: we might also desire to