Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Can not decide in this scenario:  RSS feed

 
Zee Ho
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi. Ranchers I can not decide that whether it is necessary to mark
the method which only contains one statement as synchronized


if multi-thead will visit the getCounter, do it need to be marked as synchronized? and if so, can any one explain that scenario to me? since in my mind, there is only one statement, seems impossible to block thead in it and finally make the of two different thread get the same counter value.

thx in advance.
 
Henry Wong
author
Sheriff
Posts: 22841
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The ++ operator is just syntactic sugar for a load, increment, and a store -- it is not atomic. If the method will be called by multiple threads, then you need to make it "synchronized". A few other points to consider...

1. The variable is public. It may be accessed outside of the method. Making the method "synchronized", may not work since the variable may be accessed directly.

2. Assuming it was another method, such as a simple getter or setter, which is atomic -- which means "synchronized" may not be necessary. However, if you are not going to use "synchronized" on the method, you still need to make the variable "volatile", as there are other issues which effect the variable.

3. If you have JDK 1.5, take a peek at the atomic libraries. They have classes whose ++ operators is atomic.

Henry
 
Sol Mayer-Orn
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with the previous answer, you need to synchronized.

2 minor remarks:

1) To the best of my knowledge, you'd have to synchronize even if it were "int" (rather than "long"). I don't think "int ++ " is atomic either.
Please correct me if you know otherwise.

2) An interesting thing to consider is, what if you dropped the "++" and stayed with a simple "getter", eg:

It's interesting 'cause the spec says assignmenet of *int* is atomic (e.g. int x; x=5). But assignment of *long* doesn't have to be atomic, which means if you don't synchronized *both* getter & setter you might get weird results.
However, I must add 2 reservations: first, I know it's in the spec but I've never seen it happen (I suspect all JVM's I worked with, chose to make atomic assignments for longs).
Second, this rule doesn't apply to "volatile longs" (assignments to "volatile long" must be atomic, according to spec).
 
Henry Wong
author
Sheriff
Posts: 22841
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's interesting 'cause the spec says assignmenet of *int* is atomic (e.g. int x; x=5). But assignment of *long* doesn't have to be atomic, which means if you don't synchronized *both* getter & setter you might get weird results.
However, I must add 2 reservations: first, I know it's in the spec but I've never seen it happen (I suspect all JVM's I worked with, chose to make atomic assignments for longs).
Second, this rule doesn't apply to "volatile longs" (assignments to "volatile long" must be atomic, according to spec).


One more point, there is another issue besides whether an operation is atomic or not -- and it is the caching of variables. If a variable is to be accessed by multiple threads without synchronization, the variable needs to be declared volatile, regardless of whether it is a int or a long. The reason for this is to force the JVM to not cache the variable.

Don't think you are safe because the operation is atomic !!

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!