Win a copy of The Way of the Web Tester: A Beginner's Guide to Automating Tests this week in the Testing forum!

# What is the way to resolve this (Concurrency)

Juan Manuel Alberto de los Santos
Ranch Hand
Posts: 48
This question is in sun mock exam for SCJP

what is the way to resolve it ? what calculation do i need to do ?

<blockquote>code:
<pre name="code" class="core">
class NoGo implements Runnable {

private int i;

public void run() {
if (i % 10 != 0) {
i++;
}
for (int x = 0; x < 10; x++, i++) {
if (x == 4) {
}
}
System.out.print(i + " ");
}

public static void main(String[] args) {
NoGo n = new NoGo();
for (int x = 0; x < 100; x++) {
}
}
}
</pre>
</blockquote>
Thanks.

[ UD: added missing closing CODE tag ]
[ July 17, 2008: Message edited by: Ulf Dittmer ]

Ulf Dittmer
Rancher
Posts: 42968
73
Resolve what? What is this code doing, and what were you expecting it to do?

Juan Manuel Alberto de los Santos
Ranch Hand
Posts: 48
A - The output can never contain the value 10.
B - The output can never contain the value 30.
C - The output can never contain the value 297.
D - The output can never contain the value 1020.
E - The output can never contain the value 1130.

They give 5 differents possibles answers, the correct is E ... how do i get to that result ? what calculations do i need to do ?

Ulf Dittmer
Rancher
Posts: 42968
73

satishkumar janakiraman
Ranch Hand
Posts: 334
Check the following URL How this program works?

Dariusz Kordonski
Ranch Hand
Posts: 49
This is simply all about maths: you have 100 threads, each of them (infering from run()) can increment i up to 11 times. So the maximum value the 'i' may be assigned to is 1100. Therefore values in answers A-D are all achievable

Ulf Dittmer
Rancher
Posts: 42968
73
Therefore values in answers A-D are all achievable

Unless you can show specific code paths for all 100 threads that result in any of those results, none of these need be achievable. As I said, how do you reason about what is or is not possible in non-threadsafe code?
[ July 21, 2008: Message edited by: Ulf Dittmer ]

Dariusz Kordonski
Ranch Hand
Posts: 49
But the answer options are formulated as statements: 'The output can never contain the value xxx'. I just meant that, given the code, there IS actually a possibility that values in options A-D will make it into the output. Therefore the correct answer is E, because no matter how the execution flows, you will never see 1130 in the output. That's what I meant with 'achievable' (i.e.: 'may show up in the output'). Sorry if I didn't make my point clear, I'm not a native english speaker :roll:

Mike Simmons
Ranch Hand
Posts: 3090
14
[/B]

Yes, I think that's part of the point, that i is being accessed in an unsafe manner.

Since i++ consists of reading, incrementing, and then writing the field i, it's possible for another thread to be performing these operations at the same time. However each read and write of an int field is still atomic. So no word tearing will occur here, which makes this simpler than it would be if we were talking about a long.

If two or more threads are updating i at the same time, then it's possible that the net effect will be as if only one thread had updated i - as the updates of the other threads might be overwritten by a thread that read earlier but wrote later. In this way, the effective number of increments might be reduced, by as much as a factor of 99% or so (e.g. if all 100 threads are executing each individual step at the same time, so that 99 out of 100 of the increments have no net effect) - though it's highly unlikely the reduction would be that severe. I think any value from 10 to 1099 is possible. (The (i % 0 == 0) condition must be true at least one, I'm sure, but not necessarily any more than that.)

But there's really no way to get a value greater than 1100 here. There are 100 threads, incrementing at most 11 times. Some increments might be lost due to threading issues, but there's no way to gain extra increments. So an output of 1130 will never be seen.

Dariusz Kordonski
Ranch Hand
Posts: 49
One question - what do you mean there might be problems with long? Are operations on longs not treated as atomic in Java? As I understood threads in Java, they are abstracted to the level of the JVM and managed by it internally, not necessarily directly related to OS threads. So e.g. 'long l = 5l;' would consist simply (from the point of view of the JVM, not what acually happens in CPU) of declaring variable of type long and assigning it a value. Are you saying that this is actually broken into smaller 'pieces' that might happen not to be executed atomically by a single Java thread?

Mike Simmons
Ranch Hand
Posts: 3090
14
Yes - this is covered in the Java Language Specification, here. It's only an issue for doubles and longs, because they use 64 bits, rather than 32.
[ July 22, 2008: Message edited by: Mike Simmons ]

Dariusz Kordonski
Ranch Hand
Posts: 49
Ok, I wasn't aware of that. Thank you for clearing this out!