atomicity & thread safety with primitives

[Sathvathsan Sampath]

I understood that only long and double needed explicit sychronization as they are 64 bit in size considering many of the processors are 32 bit. If this understanding is correct consider this:

Class ThreadSafety
{
private int i;
public int getInt() { return i; }
public void setInt(int var) { i = var; } // (1)
//public sychronized void setInt(int var) { i = var; } (2)
}
Question:
1) Do I need sychronized on the setter to ensure thread-safety?
My answer: No, as assignment of values to primitives other than long & double are atomic. Therefore, we don't have to worry for an i = var assignment. Say when i = 5 happens we can be assured that i will get assigned to 5 and not a garbage value.
Note: I am not referring to the order of updates to int i but only on the atomicity of assignment here. Further, even if I did put sychronized on the method it doesn't really garauntee any ordering of updates unless we do something more to the code under the application context.

Someone said sychronization on setter and getter is mandatory.
Any thoughts/views appreciated?

[Henry Wong]

Question:
1) Do I need sychronized on the setter to ensure thread-safety?

Yes, and No...

Yes, because there are other issues besides just atomic access. The JVM may also be caching your variable (or even inlining your methods). If it is not synchronized, there is a race condition between the cache and the actual variable.

And No... there is another option here. Just declare the variable as volatile, and the JVM will work with the variable (memory space) directly.

And BTW, this answer also apply to the getter.

Henry
[ November 06, 2004: Message edited by: Henry Wong ]

[Mr. C Lamont Gilbert]

Originally posted by Sathvathsan Sampath:
I understood that only long and double needed explicit sychronization as they are 64 bit in size considering many of the processors are 32 bit. If this understanding is correct consider this:

Yes/No

1. Only long and double, etc. need explicit synchronization because that is what the Java Language Specification states.

You can surmise the JLS chose to do this because they expected many JVMs would be written as 32bit machines.

You can surmise that the JVMs would be written as 32bit machines because the hardware they would be likely to run on would be 32bit.

Thus, I hope you see that Java code is abstracted and insulated from the hardware by the JVM.

Programmers should be concerned with the environment in which their code will be run. for the Java programmer that environment is mostly the JVM, but never the underlying hardware.