Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does synchronized keyword prevent reordering in Java?

Suppose I have the following code in Java

a = 5;
synchronized(lock){
    b = 5;
}
c = 5;

Does synchronized prevent reordering? There is no dependency between a, b and c. Would assignment to a first happen then to b and then to c? If I did not have synchronized, the statements can be reordered in any way the JVM chooses right?

like image 793
user1150989 Avatar asked Apr 24 '14 16:04

user1150989


2 Answers

Locking the assignment to b will, at the very least, introduce an acquire-fence before the assignment, and a release-fence after the assignment.

This prevents instructions after the acquire-fence to be moved above the fence, and instructions before the release-fence to be moved below the fence.

Using the ↓↑ notation:

a = 5;
↓ 
b = 5;
↑
c = 5;

The ↓ prevents instructions from being moved above it. The ↑ prevents instructions from being moved below it.

like image 165
dcastro Avatar answered Oct 04 '22 23:10

dcastro


Does synchronized prevent reordering?

It prevents some re-ordering. You can still have re-ordering outside the synchronized block and inside the synchronized block, but not from inside a synchronized block, to outside it.

There is no dependency between a, b and c.

That makes no difference.

Would assignment to a first happen then to b and then to c?

Yes. But as has been noted, this is not guaranteed for all JVMs. (See below)

If I did not have synchronized, the statements can be reordered in any way the JVM chooses right?

Yes, by the JVM and/or the CPU instruction optimiser and/or CPU cache, but it is unlikely given there is no obvious reason to suspect that changing the order of a = 5; and b = 5; will improve performance.

What you could see is a change of visibility for the cache. i.e. another thread reading these values could see the b = 5; before a = 5; e.g. they are on different cache lines, if it is not also synchronized.

like image 21
Peter Lawrey Avatar answered Oct 04 '22 23:10

Peter Lawrey