CODEWITHSUNDEEP
javaconcurrencyatomic
Katana24
Katana24

Reputation: 8959

Why is this statement considered Atomic?

I have a concurrent program that needs bait of clarification. The first program is considered Atomic whereas the second isn't.

NOTE: The // don't mean comments here - they mean that it is another process executing concurrently with the other.

Here is the first:

int x = 0, y = 0;

co
   x = y + 1;      // y = y + 1;
oc

The program above can be regarded as atomic - but I don't understand why this is. But this next program isn't.

int x = 0, y = 0;

co
   x = y + 1;      // y = x + 1;
oc

I know that an atomic action is a programming instruction that changes the state of a computer system indivisibly and also know that loading and storing values from/to a register is a typical atomic action. So whats going on above?

Upvotes: 2

Views: 933

Answers (3)

Marko Topolnik
Marko Topolnik

Reputation: 200296

Observe the following facts:

Example 1. Var x is not shared, only y is shared. The left thread is strictly a reader of y and the right thread is a writer of y. Since a single read or write op is atomic, there is no race condition.

Example 2. Both vars are shared; this fact alone would make the operations non-atomic, but this is even more complicated by the interdependence of reads and writes. Left thread: read of y is followed by write of x, right thread: read of x is followed by a write of y. These ops can be interleaved in any order; even orderings incompatible with program order are possible.

In the first example any execution will end up with results that can be interpreted either as x = y + 1; being executed before y = y + 1; or the other way round. The second one may end up with results that are incompatible with either of these interpretations -- that's why the ops are not atomic.

Upvotes: 1

Hot Licks
Hot Licks

Reputation: 47759

In your first case you will always encounter y either before or after the increment. Since operations are async you can't tell which, but it doesn't make any difference -- the only observable effect is that x is larger by 1 in one case rather than the other, and this could have occurred based on ordering of the two statements.

In the second case, you can get a situation where the resulting values of x and y are not consistent with either ordering of the statements, because x and y were both fetched before either was modified.

The first case is not really Java's definition of "atomic" (and has nothing to do with any "atomic" directives that might be generated by the compiler), but simple programming.

Upvotes: 3

Kumar Vivek Mitra
Kumar Vivek Mitra

Reputation: 33544

Mostly atomic in terms of thread means that A block of statement need to be accessed and proceeded completely before another thread can access it. Its like this

x= x+1 ;

now when a tread is accessing variable x to read and write its value, if other thread also try to read and write it, then due to unlucky timing (called Race Condition) will cause problem, like thread A reads variable x value which may be 0, and at that time thread B read and writes the value to x as 1, now when thread A writes the value to x which will be also 1, as thread A knows that x is 0, but actually its 1.

int x = 0, y = 0;

co
   x = y + 1;      // y = y + 1;
oc

Is atomic as x, and y values must be read and written by the same thread at a time, if more than one thread access it, then it will give inconsistent results.

int x = 0, y = 0;

co
   x = y + 1;      // y = x + 1;
oc

On other hand this is not atomic, as x=y+1 will not effect y=x+1 as per fetch on x and y is done here.

Upvotes: 0

Related Questions