On Wed, May 25, 2016 at 12:53 AM, Paul Sandoz <[email protected]> wrote: > >> On 25 May 2016, at 01:15, Martin Buchholz <[email protected]> wrote:
>> We already sort-of have an existing field qualifier for atomic: "volatile" ! >> It is already the case that e.g. volatile long is atomic while >> unadorned long is not. >> But atomics without CAS make us sad, so we're adding them. >> Also, by analogy, Atomic*FieldUpdaters must refer to a volatile variable. >> It seems not unreasonable to require that VarHandles also refer to a >> volatile field. >> > > We wanted the flexibility to perform “normal" plain access against other > accesses using a VarHandle, of course that requires very careful use. > Furthermore, other operations anyway override that of the volatile semantics. A*FU also provides API to weaken the normal semantics of volatile - e.g. (the poorly named and specified) lazySet. So it is already the case that there is no global sequential consistent order in Java for all memory operations on fields marked volatile! (It's true that there is no "volatile" for array elements) The dynamic nature of VarHandle bothers me a little. Static analysis tools cannot discover fields being used with atomic operations with certainty. Even though in practice most uses of VarHandles will be to fields declared "nearby".
