... without additional synchronization ? The Tree class below is meant to be accessed by multiple threads (it is a singleton but not implemented via an enum)
class Tree {
private volatile Node root;
Tree() {
root = new Node();
// the threads are spawned _after_ the tree is constructed
}
private final class Node {
short numOfKeys;
}
}
Will updates to the numOfKeys field be visible to reader threads without any explicit synchronization (notice that both readers and writers have to acquire an instance of ReentrantReadWriteLock - same instance for each node - but barring that) ? If not would making numOfKeys volatile suffice ?
Is changing the root as simple as root = new Node() (only a writer thread would change the root, apart from the main thread which calls the Tree constructor)
Related:
multiple fields: volatile or AtomicReference?
Is volatile enough for changing reference to a list?
Are mutable fields in a POJO object threadsafe if stored in a concurrentHashMap?
Using volatile keyword with mutable object
EDIT: interested in post Java 5 semantics
No.
Placing a reference to an object in a volatile field does not affect the object itself in any way.
Once you load the reference to the object from the volatile field, you have an object no different from any other object, and the volatility has no further effect.
The are two question. Let's start with the second.
Assigning newly constructed objects to volatile variables works nicely. Every thread, that reads the volatile variable, will see a fully constructed object. There is no need for further synchronization. This pattern is usually seen in combination with immutable types.
class Tree {
private volatile Node node;
public void update() {
node = new Node(...);
}
public Node get() {
return node;
}
}
Regarding the first question. You can use volatile variables to synchronize access to non-volatile variable. The following listing shows an example. Imagine that the two variables are initialized as shown, and that the two methods are executed concurrently. It is guaranteed, that if the second thread sees the update to foo, it will also see the update to bar.
volatile int foo = 0;
int bar = 0;
void thread1() {
bar = 1;
foo = 1; // write to volatile variable
}
void thread2() {
if (foo == 1) { // read from volatile variable
int r = bar; // r == 1
}
}
However, your example is different. The reading and writing might look as follows. In contrast to the above example, both threads read from the volatile variable. However, read operations on volatile variables do not synchronize with each other.
void thread1() {
Node temp = root; // read from volatile variable
temp.numOfKeys = 1;
}
void thread2() {
Node temp = root; // read from volatile variable
int r = temp.numOfKeys;
}
In other words: If thread A writes to a volatile variable x and thread B reads the value written to x, then after the read operation, thread B will see all write operations of thread A, that occurred before the write to x. But without a write operation to a volatile variable, there is no effect on updates to other variables.
That sounds more complicated than it actually is. Actually, there is only one rule to consider, which you can find in JLS8 §17.4.5:
[..] If all sequentially consistent executions are free of data races, [..] then all executions of the program will appear to be sequentially consistent.
Simply put, a data race exists if two threads can access the same variable at the same time, at least one operation is a write operation, and the variable is non-volatile. Data races can be eliminated by declaring shared variables as volatile. Without data races, there is no problem with visibility of updates.
Related
Consider the following code:
public class Resource {
public int val;
public Resource() {
val = 3;
}
}
public class UnsafePublication {
public static Resource resource;
public static void initialize() {
resource = new Resource();
}
}
In Thread1
UnsafePublication.initialize();
In Thread2
while (true) {
if (UnsafePublication.resource != null) {
System.out.println(UnsafePublication.resource.val);
break;
}
}
We know that the unsafe publication may lead to Thread2 printing 0 instead of 3.
After going through many reference materials, I concluded two explanations:
Assume the assignment resource = new Resource(); does write through, so Thread2 will find UnsafePublication.resource is not null. But the assignment val = 3; in the constructor of Resource does not write through, so the val will be the default 0 value.
There is a reorder when assigning new Resource() to resource. To be more specific:
allocate the memory for a Resource object
call Resource' s constructor to initialize the object
assign the object to the field "resource"
is reordered to:
allocate the memory for a Resource object
assign the object to the field "resource"
call Resource' s constructor to initialize the object.
So if Thread1 just finishes the step2 in the reordered version, and Thread2 is swapped in, then Thread2 will find UnsafePublication.resource.val is the default 0 value.
So here is my question: Are both of the explanations correct and possible? And in the real world, are these two factors may even mixed to make the situation more complicated?
There are three possibilities here.
Thread2 may view resource as null.
Thread2 may view a reference to a partially constructed instance (i.e. memory is allocated on the heap, but the variables are not yet initialized), so the value of val variable might be zero.
Thread2 may observe a fully constructed instance and the latest value of the variable, which is 3.
In fact, you can't predict the behavior of the program since there's no any happens before link established between the write and subsequent read operations. So, all the combinations of events are possible.
say I have the following two classes.
public class Foo {
private volatile Integer x = 0;
private volatile boolean istrue = false;
public void setInt(int x) {
this.x = x;
}
public void setBoolean(boolean istrue) {
this.istrue = istrue;
}
public Integer getInt() {
return x;
}
}
vs
public class Bar {
private volatile AtomicInteger x = 0;
private volatile AtomicBoolean istrue = false;
public void setInt(int x) {
this.x.set(x);
}
public void setBoolean(boolean istrue) {
this.istrue.set(istrue);
}
public Integer getInt() {
return this.x.get();
}
}
Assume multiple threads can access Foo or Bar. Are both classes thread safe? what is the difference between the two classes really?
In the current example you have single assignment statements in the methods. I think you need to come up with a better example. Because the assignment will be executed in a single instruction. Which makes both the implementation thread safe. Even though, it is possible that, two different threads see different values of the int when they access them, because by the time, other thread can potentially reset (set) to a different value.
Check this out: What is thread Safe in java?
Both classes are thread safe as written. The difference between use of a volatile variable and the java.util.concurrent.atomic classes is that the atomic classes permit more complex operations, such as compare and set, to be performed atomically. With just direct access to a volatile variable, there could be a thread context switch between the compare and the set, so you can't rely on the result of the compare still being valid when the set is done.
Both classes are thread safe. But that is not your issue here.
Foo: reads and writes to the fields are atomic. But more complex operations such as i++ are not. i++ translates to i = i + 1, which decomposes to a read and a write, so there could a thread context switch in between making the entire operation not atomic.
Bar: the volatile makes the access to the Atomic fields themselves atomic, so you can reassign the fields with new references in an atomic ways. The operations on the fields like compareAndSet or inc however are atomic. Question is, do you need atomic write access to the fields or just atomicity on the operations? As the AtomicXXX type are just containers for for values, you typically don't reassign the variable, but reassign values, which is atomic.
So this should be sufficient:
private final AtomicInteger x = new AtomicInteger(0);
private final AtomicBoolean istrue = new AtomicBoolean(false);
Below is the code snippet from concurrency in practice.
class OneValueCache {
private final BigInteger lastNumber;
private final BigInteger[] lastFactors;
public OneValueCache(BigInteger i,BigInteger[] factors) {
lastNumber = i;
lastFactors = Arrays.copyOf(factors, factors.length);
}
public BigInteger[] getFactors(BigInteger i) {
if (lastNumber == null || !lastNumber.equals(i))
return null;
else
return Arrays.copyOf(lastFactors, lastFactors.length);
}
}
//Volatile is not enough to make VolatileCachedFactorizer thread safe? Why we need final specifier in OneValueCache.
public class VolatileCachedFactorizer implements Servlet {
private volatile OneValueCache cache = new OneValueCache(null, null);
//Servlet service method.
public void service(ServletRequest req, ServletResponse resp) {
BigInteger i = extractFromRequest(req);
BigInteger[] factors = cache.getFactors(i);
//Check factors are null or not.
if (factors == null) {
factors = factor(i);
cache = new OneValueCache(i, factors);
}
encodeIntoResponse(resp, factors);
}
}
What is the use of declaring fields as final in OneValueCache. "volatile OneValueCache cache" makes sure that object is visible to all the other threads and i assume that writes before volatile write is visible to all the other threads.
Final fields make OneValueCache immutable, thereby making it thread safe. They also have special semantics defined by the JLS, in particular, any thread will be able to see the correctly constructed object with the final fields initialized to its only correct value.
If this was not the case, and the fields happened to not be final, other threads might not be able to see the changes, even made in the constructor, because without final fields, there are no construction safety guarantees.
JCIP explains that OneValueCache is only an immutable reference class used to hold to the two bits of data. This is safer than updating two fields in the method, as it is not atomic. Then, OneValueCache is made volatile in the servlet because it needs to be changed, but is an atomic assignment, so no synchronization is needed.
They are two different things.
Generally,
volatile --> Creates a memory barrier which enforces the data in the cache to be flushed and forces data to be read from the main memory. So, all threads can always get the updated data for this particular field.
final -->
for primitives --> specifies that the value cannot change
for non-primitives --> The references cannot change (i.e, reference cannot point to another object).
For an object / field to be immutable, you need to ensure that it is transitively accessible by final fields and a reference of it doesn't escape.
PS : final and immutability are two different concepts. So, if you've heard of immutability, please understand that it is different from final.
It looks like the intention of OneValueCache class is to be immutable so declaring the values to be final just guarantees that at some later stage a programmer doesnt try to extend the class and overwrite the values.
... without additional synchronization ? The Tree class below is meant to be accessed by multiple threads (it is a singleton but not implemented via an enum)
class Tree {
private volatile Node root;
Tree() {
root = new Node();
// the threads are spawned _after_ the tree is constructed
}
private final class Node {
short numOfKeys;
}
}
Will updates to the numOfKeys field be visible to reader threads without any explicit synchronization (notice that both readers and writers have to acquire an instance of ReentrantReadWriteLock - same instance for each node - but barring that) ? If not would making numOfKeys volatile suffice ?
Is changing the root as simple as root = new Node() (only a writer thread would change the root, apart from the main thread which calls the Tree constructor)
Related:
multiple fields: volatile or AtomicReference?
Is volatile enough for changing reference to a list?
Are mutable fields in a POJO object threadsafe if stored in a concurrentHashMap?
Using volatile keyword with mutable object
EDIT: interested in post Java 5 semantics
No.
Placing a reference to an object in a volatile field does not affect the object itself in any way.
Once you load the reference to the object from the volatile field, you have an object no different from any other object, and the volatility has no further effect.
The are two question. Let's start with the second.
Assigning newly constructed objects to volatile variables works nicely. Every thread, that reads the volatile variable, will see a fully constructed object. There is no need for further synchronization. This pattern is usually seen in combination with immutable types.
class Tree {
private volatile Node node;
public void update() {
node = new Node(...);
}
public Node get() {
return node;
}
}
Regarding the first question. You can use volatile variables to synchronize access to non-volatile variable. The following listing shows an example. Imagine that the two variables are initialized as shown, and that the two methods are executed concurrently. It is guaranteed, that if the second thread sees the update to foo, it will also see the update to bar.
volatile int foo = 0;
int bar = 0;
void thread1() {
bar = 1;
foo = 1; // write to volatile variable
}
void thread2() {
if (foo == 1) { // read from volatile variable
int r = bar; // r == 1
}
}
However, your example is different. The reading and writing might look as follows. In contrast to the above example, both threads read from the volatile variable. However, read operations on volatile variables do not synchronize with each other.
void thread1() {
Node temp = root; // read from volatile variable
temp.numOfKeys = 1;
}
void thread2() {
Node temp = root; // read from volatile variable
int r = temp.numOfKeys;
}
In other words: If thread A writes to a volatile variable x and thread B reads the value written to x, then after the read operation, thread B will see all write operations of thread A, that occurred before the write to x. But without a write operation to a volatile variable, there is no effect on updates to other variables.
That sounds more complicated than it actually is. Actually, there is only one rule to consider, which you can find in JLS8 §17.4.5:
[..] If all sequentially consistent executions are free of data races, [..] then all executions of the program will appear to be sequentially consistent.
Simply put, a data race exists if two threads can access the same variable at the same time, at least one operation is a write operation, and the variable is non-volatile. Data races can be eliminated by declaring shared variables as volatile. Without data races, there is no problem with visibility of updates.
I was reading book "java concurrency in practice" and end up with some doubts after few pages.
1) Voltile with non premitive data types :
private volatile Student s;
what is significance of volatile when it comes with non premitive data types ? (I think in this case only think that is sure to be visible to all threads is what Strudent object s is pointing currently and it is possible one thread A modifies some internal member of student and that is not visible to other threads. Am I right ??)
2)
Is a variable can be immutable , even if internal members are not declared as final ??
For example :
Class A {
private Set<String> s = new Set();
public A() {
s.add("Moe");
s.add("Larry");
s.add("Curly");
}
}
In this class do we need to make Set s final to make it immutable or this class is still immutable ? (because even in this case we can't change state of object after it is created).
3 ) There is one example in book that shows how to use volatile and immutable class in combination to get synchronization. Before I put that question I have one more doubt.
suppose there is some function like this :
private Student s = new Student;
void func() {
s.func2(); // 1
if(s.isPossible()) { //2
s = new Student(); //3
}
}
a)func2() acess internal members of s. Now consider Thread A entered into func2 after executing line 1 and Thread B same time reassign s with new object. When Thread A resumes
what it will use new object or the old one ? ( suppose s initally points to memory location 100 (old object) and after a new object is assigned it started pointing to 200 (new object)
then when Thread A resumes it will acess address 100 or address 200).
b) If I make s volatile , will it make any difference to above case.
4.) And here is last one
#Immutable
class OneValueCache {
private final BigInteger lastNumber;
private final BigInteger[] lastFactors;
public OneValueCache(BigInteger i,
BigInteger[] factors) {
lastNumber = i;
lastFactors = Arrays.copyOf(factors, factors.length);
}
public BigInteger[] getFactors(BigInteger i) {
if (lastNumber == null || !lastNumber.equals(i))
return null;
else
return Arrays.copyOf(lastFactors, lastFactors.length);
}
}
#ThreadSafe
public class VolatileCachedFactorizer implements Servlet {
private volatile OneValueCache cache = new OneValueCache(null, null);
public void service(ServletRequest req, ServletResponse resp) {
BigInteger i = extractFromRequest(req);
BigInteger[] factors = cache.getFactors(i); // Position A
if (factors == null) {
factors = factor(i);
cache = new OneValueCache(i, factors); // Position B
}
encodeIntoResponse(resp, factors);
}
}
Accroding to book class "VolatileCachedFactorizer" is thread safe. Here is my reasoning why it is thread safe (Correct me if I am wrong.) Positin A and Position B are
doubtful positions.
Position A : As cache is pointing to immutable object , any function call is safe (right ?).
Position B : It can have two issue
a)Threads see cache improperly initialized . Not possible in this case as immutable object are guaranteed to be properly initialized (right ?).
b)New assigned object not visible to other threads. Not possible is this case as cache is volatile (right ?).
But it is possible thread A call getFactors() and other thread B reassign cache , in this case A will continue to see old object (right ?)
Yes; volatile only applies to the reference it's applied to.
No; objects that happen to be pointed to by final fields do not magically become immutable.
An object with mutable non-public members is only immutable if those members can never be mutated. (obviously)
Found out after some testing all my answers.
volatile only applies to reference. Any object point by volatile object need not to be visible other threads.
Yes final is important. Without it object of class will not be immutable.
Suppose a variable "obj" is pointing to location x(where the actual object is placed) when a function call on obj is started then during function call all member variables will be read from location x even if some other thread assign a different object on "obj".
Assumed explanations for all answers are correct.