Consider the following simple example:
public class Example extends Thread {
private int internalNum;
public void getNum() {
if (internalNum > 1)
System.out.println(internalNum);
else
System.out.println(1000);
}
public synchronized modifyNum() {
internalNum += 1;
}
public void run() {
// Some code
}
}
Let's say code execution is split in two threads. Hypothetically, following sequence of events occurs:
- First thread accesses the
getNum
method and caches theinternalNum
which is 0 at the moment. - At the very same time second thread accesses
modifyNum
method acquiring the lock, changes theinternalNum
to 1 and exits releasing the lock. - Now, first thread continues it execution and prints the
internalNum
.
The question is what will get printed on the console?
My guess is that this hypothetical example will result in 1000 being printed on the console because read and write flushes are only forced on a particular thread when entering or leaving the synchronized block. Therefore, first thread will happily use it's cached value, not knowing it was changed.
I am aware that making internalNum
volatile would solve the possible issue, however I am only wondering weather it is really necessary.
I think you mix things. Your class extends
Thread
but your question is about accessing to a resource of a same instance by concurrent threads.Here is the code adapted to your question.
A shared resource between threads :
Threads and running code :
Your question :
In your scenario you give the impression that the
modifyNum()
method execution blocks the other threads to access to non synchronized methods but it is not the case.getNum()
is not synchronized. So, threads don't need to acquire the lock on the object to execute it. In this case, the output depends simply of which one thread has executed the instruction the first :or