Assessing the scalability of programs and algorithms on multicore is critical. There is an important literature on locks and locking schemes, but the exact cost of volatile is less clear.
- Are volatile really free?
- Is volatile expensive?
- Java’s Atomic and volatile, under the hood on x86
- Cost of Volatile
For the software composition seminar, Stefan Nüsch and I decided to look at this topic. Essentially, we devised a benchmark where multiple threads would access objects within a pool. Each thread has a set of objects to work with. To generate contention, the sets could be fully disjointed, have partial overlap, of have a full overlap. The ratio of reads and writes per thread was also configurable.
On an AMD 64 Dual Core, the graph looks as follows:
In future work, we could try to reproduce false sharing and assess the impact of other forms of data locality.
Here a some links about the semantics of volatile, and mememory management in general.
- Java Concurrency (&c): What Volatile Means in Java
- The Java Memory Model here, and the POPL’05 paper
- An Operational Semantics including “Volatile” for Safe Concurrency, JOT 09
- Double-checked locking is broken
- Thin locks: featherweight synchronization for Java, PLDI 98
- Memory Barriers: a Hardware View for Software Hackers
- What Every Programmer Should Know About Memory
- False Sharing
- Relaxed-Memory Concurrency
- The Silently Shifting Semicolon