Why is i++ not atomic?

by

i++ is probably not atomic in Java because atomicity is a special requirement which is not present in the majority of the uses of i++. That requirement has a significant overhead: there is a large cost in making an increment operation atomic; it involves synchronization at both the software and hardware levels that need not be present in an ordinary increment.

You could make the argument that i++ should have been designed and documented as specifically performing an atomic increment, so that a non-atomic increment is performed using i = i + 1. However, this would break the “cultural compatibility” between Java, and C and C++. As well, it would take away a convenient notation which programmers familiar with C-like languages take for granted, giving it a special meaning that applies only in limited circumstances.

Basic C or C++ code like for (i = 0; i < LIMIT; i++) would translate into Java as for (i = 0; i < LIMIT; i = i + 1); because it would be inappropriate to use the atomic i++. What’s worse, programmers coming from C or other C-like languages to Java would use i++ anyway, resulting in unnecessary use of atomic instructions.

Even at the machine instruction set level, an increment type operation is usually not atomic for performance reasons. In x86, a special instruction “lock prefix” must be used to make the inc instruction atomic: for the same reasons as above. If inc were always atomic, it would never be used when a non-atomic inc is required; programmers and compilers would generate code that loads, adds 1 and stores, because it would be way faster.

In some instruction set architectures, there is no atomic inc or perhaps no inc at all; to do an atomic inc on MIPS, you have to write a software loop which uses the ll and sc: load-linked, and store-conditional. Load-linked reads the word, and store-conditional stores the new value if the word has not changed, or else it fails (which is detected and causes a re-try).

More Related Contents:

  1. Why must wait() always be in synchronized block
  2. When and how should I use a ThreadLocal variable?
  3. ExecutorService that interrupts tasks after a timeout
  4. What is the difference between Thread.start() and Thread.run()?
  5. Volatile vs Static in Java
  6. When would you call java’s thread.run() instead of thread.start()?
  7. Why use a ReentrantLock if one can use synchronized(this)?
  8. Java Executors: how can I set task priority?
  9. What are the main uses of yield(), and how does it differ from join() and interrupt()?
  10. Volatile variable in Java
  11. What is the JVM thread scheduling algorithm?
  12. How do I implement task prioritization using an ExecutorService in Java 5?
  13. Why does Thread.isInterrupted () always return false?
  14. More efficient way for pausing loop wanted
  15. When should I use a CompletionService over an ExecutorService?
  16. How does `this` reference to an outer class escape through publishing inner class instance?
  17. Are non-synchronised static methods thread safe if they don’t modify static class variables?
  18. Java ExecutorService: awaitTermination of all recursively created tasks
  19. Which concurrent Queue implementation should I use in Java?
  20. Why should I use concurrent characteristic in parallel stream with collect?
  21. Jboss Java EE container and an ExecutorService
  22. Why doesn’t volatile in java 5+ ensure visibility from another thread?
  23. Thread Confinement
  24. How to pause/resume all threads in an ExecutorService in Java?
  25. Multithreading Socket communication Client/Server
  26. Java, divide incoming work uniformly via hashing in multithreaded evnironments
  27. LinkedBlockingQueue vs ConcurrentLinkedQueue
  28. Setting Ideal size of Thread Pool [duplicate]
  29. Does a breakpoint halt all threads?
  30. Are 64 bit assignments in Java atomic on a 32 bit machine?

Leave a Comment