2

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?

Improve this question
3
  • @Keyser: read all of it - those aren't comments Commented May 18, 2012 at 11:06
  • 1
    You should really stress your last line Commented May 18, 2012 at 11:09
  • @MichaelBorgwardt yep, I see it. Commented May 18, 2012 at 11:14

3 Answers 3

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

You can call them atomic because they are always executed as a whole, only their ordering is unknown.
Yes, but it has nothing really to do with Java's "atomic" implementation -- it's inherently atomic.
By Java's "atomic" implementation you mean... AtomicReference? A volatile var?
I forget what the various incantations are -- I get my different languages all confused, but the whole set of synchronized, volatile, the concurrent/atomic classes, et al. These all involve using some machine instructions that tell the processor to synchronize memory, one way or the other, whereas the above code sequences do not, and the first doesn't need it.
But there's the notion of atomic operations on a Java int, which do apply here.
|
1

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.

Improve this answer

Comments

0

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.

Improve this answer

1 Comment

How can x = y + 1 not affect the second process if they are both involve the same variables? I have determined that the possible values of x and y for the first program are: assuming Process A then Process B; x = 1, y = 1. B before A; x = 2, y = 1. In the non-atomic program, assuming A executes before B; x = 1, y = 2. Finally B before A; x = 2, y = 1.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.