This week's book giveaways are in the Cloud and AI/ML forums.
We're giving away four copies each of Cloud Native Patterns and Natural Language Processing and have the authors on-line!
See this thread and this one for details.
Win a copy of Cloud Native PatternsE this week in the Cloud forum
or Natural Language Processing in the AI/ML forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

What makes AtomicInteger atomic or thread-safe? Is it synchronized bydefault?

 
Ranch Hand
Posts: 232
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what kind of lock system does AtomicInteger uses?
 
Bartender
Posts: 2323
100
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can check the source code of AtomicInteger for it's implementation. I feel that the most important line is this one:

Further details here: https://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html
 
Saloon Keeper
Posts: 10396
221
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Definitely not. The volatile keyword doesn't make field access atomic, it just establishes a memory barrier.

Atomicity is achieved by calling jdk.internal.misc.Unsafe.compareAndSetInt(), which is a native method and thus not implemented in terms of Java. It likely uses some special CPU instruction that updates the value atomically without having to resort to locks.

Locking and synchronizing would have made AtomicInteger much too slow.
 
Ranch Hand
Posts: 401
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Stephan, how it will behave if some CPU doesn't support those kind of special instructions set?
 
Saloon Keeper
Posts: 5698
144
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:The volatile keyword doesn't make field access atomic, it just establishes a memory barrier.


Hm, that does seem to contradict this:

Page Salvin linked to wrote:Reads and writes are atomic for all variables declared volatile


 
Marshal
Posts: 64998
246
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It wouildn't work. Do you know any CPUs that don't support whichever instruction that is?
 
Tim Moores
Saloon Keeper
Posts: 5698
144
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Vaibhav Gargs wrote:how it will behave if some CPU doesn't support those kind of special instructions set?


It could be that on such a CPU it's not possible to run a JVM. But that's just speculation on my part, as I have no idea if such CPUs exist in contexts where one might like to run JVMs.
 
Vaibhav Gargs
Ranch Hand
Posts: 401
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:It wouildn't work. Do you know any CPUs that don't support whichever instruction that is?



Hi Campbell, I am not sure if any such CPU exists but since these are some special instructions such as CAS etc. which made me think that these instructions will be supported by all CPUs or not?
 
Campbell Ritchie
Marshal
Posts: 64998
246
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know. I am afraid I think you will have to search for them.
 
Stephan van Hulst
Saloon Keeper
Posts: 10396
221
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:

Stephan van Hulst wrote:The volatile keyword doesn't make field access atomic, it just establishes a memory barrier.


Hm, that does seem to contradict this:

Page Salvin linked to wrote:Reads and writes are atomic for all variables declared volatile



I apologize, I should have said: "The volatile keyword doesn't make ALL field access atomic.". Yes, a write like x = 3L is atomic when x is volatile, even when x is a long. However, an operation like x++ is still composed of three smaller operations that are NOT executed as a single atomic one:

AtomicInteger.getAndIncrement() emulates x++, except that it's atomic.

Vaibhav Gargs wrote:Dear Stephan, how it will behave if some CPU doesn't support those kind of special instructions set?


Then the native code will mimic the CPU instruction, likely by using locks. So AtomicInteger works fine for such machines, but it would be slower.
 
salvin francis
Bartender
Posts: 2323
100
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To be fair to the OP, since we're discussing all the possibilities, I think my original answer needs more elaboration.

Arun Singh Raaj wrote:what kind of lock system does AtomicInteger uses?



AtomicInteger internally uses a volatile int variable. The link I posted gives more information about the atomic access, specifically:

oracle docs wrote:Reads and writes are atomic for all variables declared volatile (including long and double variables).



However, since reads and writes are atomic, we cannot simply use the getters and setters out of the box. Here's what would bring a frown on my face:
To ensure atomic modifications including increment, decrement, delta updates, etc.. AtomicInteger gives methods such as getAndIncrement(), incrementAndGet() etc...
Internally, these methods are implemented using native methods. We can only speculate how this in internally implemented per machine. If the implementations differ, their performances may differ too.
 
author
Posts: 23834
140
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Arun Singh Raaj wrote:what kind of lock system does AtomicInteger uses?



The AtomicInteger class uses a technique call "optimistic locking". This means that there isn't any locks...  

Instead, there is a mechanism that is used to detect collisions -- and of course, if it does collide, then there is a mechanism to resolve it (which is just to retry the operation, in most cases). The idea is... since a collision will not happen for a majority of cases, it will run really fast (since there isn't any locks).

Henry
 
Henry Wong
author
Posts: 23834
140
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Vaibhav Gargs wrote:
Hi Campbell, I am not sure if any such CPU exists but since these are some special instructions such as CAS etc. which made me think that these instructions will be supported by all CPUs or not?



The CAS instruction is supported by all modern day processors. Keep in mind that the CAS instruction is also needed by the JVM to implement synchronization, so, if the CAS instruction doesn't exist (like with really old JVMs), then a work around has already been implemented.

Henry
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!