CS4282/CS6282 Internet and Distributed Systems Programming

CS4282/CS6282 Internet and Distributed Systems Programming

Doug Lea : Concurrent Programming in Java

Notes : page 93, 97

volatile fields

1. In terms of atomicity, visibility, and ordering, declaring a field as volatile is nearly identical in effect to using a little fully synchronized class protecting ONLY that field via get or set methods.

2. A field CANNOT be both final and volatile. Declaring a field as volatile differs only in that NO locking is involved. In particular, COMPOSITE read/write operations such as "++ " operation on volatile variables are NOT performed atomically.

3.Also, ordering and visibility effects surround ONLY the SINGLE access or update to the volatile field itself. Declaring a reference field as volatile does NOT ensure visibility of NON-volatile fields that are accessed via this reference.

4. Declaring an field field as volatile does NOT ensure visibility of its elements. Volatility CANNOT be manually propagated for arrays because array elements themselves CANNOT be declared as volatile.

5. Accesses and updates to the memory cells corresponding to fields of any type EXCEPT long or double are guaranteed to be atomic. This includes fields serving as references to other objects. Additionally, atomicity extends to volatile long and volatile double.