Instruction reordering

Advertisement
According to Java Memory Model instruction "reordering produces results consistent with a legal execution, it is not illegal."
I have an array of longs shared between multiple readers and one writer.
Here is simplified writer code.
long a = getA();                // line 1 
long b = getB();                // line 2
long value = a << 14 + b;   // line 3
int index = getIndex();         // line 4
sharedArray[index] = value;   // line 5Is it possible that compiler reorders instructions in a way such that it will look like the following code?
long a = getA();   // line 1              
long b = getB();   // line 2             
int index = getIndex();    // line 3  
sharedArray[index] = a;  // line 4
sharedArray[index] = (sharedArray[index] << 14 + b); // line 5 This is valid for single-thread execution, but in multi-threaded environment, if reader thread reads a value from a sharedArray after line 4, but before line 5, then it will be invalid. If it possible, then is there a way to a avoid that without using any locks and volatile variables?
Sergey.
Advertisement

Replay

serezha wrote:
Skip...
Is it possible that compiler reorders instructions in a way such that it will look like the following code?
Skip...No, this is not possible. I suppose you use 3rd edition of JLS (becase you refers to a "happens before ordership" in your other post). And in this edition JLS states "The actions of each thread in isolation must behave as governed by the semantics of that thread, with the exception that the values seen by each read are determined by the memory model" (chapter 17.4). The examples have different number of read/writes (first have one write, second - two writes and one read), and second example can't be the reordering of the first (but the first can be the "reordering" of the second). A compiler (or JVM) can't add new reads or writes (because they are not present in the original code), but can remove them (it can be emulated by the proper "write observed" function).
This is valid for single-thread execution, but in multi-threaded environment,
if reader thread reads a value from a sharedArray after line 4, but before line 5,
then it will be invalid. If it possible, then is there a way to a avoid that without using any locks and volatile variables?Why are you trying to avoid any kind of the synchronization? Is it proven as bottleneck? And still, thing are much more worse. In your example, you must have some means of synchronization, because you have a "critical section" - reads and writes of longs are not atomic (JLS 3rd, 17.7). Thus there must be a correct synchronization between reads and writes of a sharedArra[index].