CODEWITHSUNDEEP
javavisibilityatomicvolatile
lockfreecode
lockfreecode

Reputation: 3

Visibility guarantees of atomic variables

Having read lots about volatile, atomic and visibility, one question remains. Following works across threads, "a" is visible all the time, when "b" is updated/read:

int a;
volatile int b;
a = 1; b = 1;
...
// different thread
if (b == 1) // do something with a, which is 1 now

Does the same hold true with atomic variables, which are separate objects, will the following work?

int a;
AtomicInteger b = new AtomicInteger();
a = 1; b.set(1);
...
// different thread
if (b.get() == 1) // a guaranteed to be 1 here all the time ???

If the answer is no, then it should work to extend the AtomicInteger class and include "a" within there, because AtomicInteger wraps a volatile.

Upvotes: 0

Views: 230

Answers (3)

Eugene
Eugene

Reputation: 120988

If only the documentation would not specify that explicitly:

Sets the value of a variable to the newValue, with memory semantics of setting as if the variable was declared volatile.

If that is the only code you have that work on that AtomicInteger, then yes, a is guaranteed to be 1.

Upvotes: 1

Prashant Pandey
Prashant Pandey

Reputation: 4642

A get() is equivalent to reading from a volatile variable, and a set() is equivalent to writing to it. We have a happens-before relationship here write -> read and therefore, "a guaranteed to be 1 here all the time". This of course is in the context of only these two threads executing.

Upvotes: 1

Andy Turner
Andy Turner

Reputation: 140504

a guaranteed to be 1 here all the time ???

No, other set calls can happen in between.

But then this is also true in the volatile case.

Upvotes: 0

Related Questions