2

I have a need for a long instance variable.
This variable will hold some event time (time in milliseconds).
If i'm only setting values into this long and getting the value,
is there any advantage of using AtomicLong (and only its get() and set()) rather than long?

Shayan Ghosh
  • 862
  • 6
  • 14
inor
  • 2,423
  • 2
  • 22
  • 39
  • 1
    Depends if multi-threadness and thread-safety is involved. – Tunaki Sep 09 '15 at 08:28
  • Suppose i run it in a multi-threaded context... how is the AtomicLong advantageous? – inor Sep 10 '15 at 11:17
  • See also [What is the difference between atomic / volatile / synchronized?](https://stackoverflow.com/questions/9749746/what-is-the-difference-between-atomic-volatile-synchronized) – Vadzim Oct 08 '19 at 09:41

4 Answers4

2

Look at the doc of AtomicLong

An AtomicLong is used in applications such as atomically incremented sequence numbers, and cannot be used as a replacement for a Long.

This specific class is designed to use in multi threaded environment for thread safety.

Do not use it unless you need thread safety. You can provide your own getter and setters for your long variable, if you want only those methods.

Suresh Atta
  • 114,879
  • 36
  • 179
  • 284
  • In a multi-threaded environment, suppose some threads are setting the value and some are getting it... how is x=myAtomicLongVar.get() better than x=mySinpleLongVar? what thread safety does it provide? – inor Sep 10 '15 at 11:15
1

Yes there are advantages.

  1. In a multithreaded environment you will get predictable results between threads.
  2. It is a convenient mutable long.

However, if you are not operationg in a multithreaded environment and all you want is a mutable long you would be better to use your own mutable object. Using AtomicLong in this case would be confusing for others and will perform unnecessary cache management.

OldCurmudgeon
  • 60,862
  • 15
  • 108
  • 197
  • `you would be better to use your own mutable object` - that is questionable or I misunderstood the statement somehow, because for me it sounds like "you better to use mutable wrapper instead of primitive everywhere" – Dmitry Zaytsev Sep 09 '15 at 09:12
  • @DmitryZaitsev - Now reads *... and all you want is a mutable long you would be better to use your own mutable object* - hope that is better. – OldCurmudgeon Sep 09 '15 at 09:24
  • @OldCurmudgeon Suppose it is in a multi-threaded... Can you show an example in which get/set of AtomicLong result in more predictable results than a simple assignment and retrieval of a long? – inor Sep 10 '15 at 11:20
  • @inor - `AtomicLong.incrementAndGet()` happening from two different threads at the same time would certainly result in the value being incremented twice. `long++` from two threads at the same time could result in only one increment. `volatile long++` could result in in only one increment. – OldCurmudgeon Sep 10 '15 at 12:55
  • @OldCurmudgeon - You are right, BUT "If i'm only setting values into this long and getting the value"? (not incrementing or adding 10 to it or any other operation) – inor Sep 13 '15 at 05:33
0

If you are not using its value in its own updates, you don't need it, but if you intend to do something like var.set(1+var.get()) and you use several threads there's, among others, this possibility:

Thread 1: x=var.get(); x=x+1;

Thread 2: y=var.get(); y=y+1;

Thread 1: var.set(x);

Thread 2: var.set(y);

With that sequence, the user expects the value to have been increased by 2, but they'll see it's been increased only by 1

dtortola
  • 718
  • 4
  • 6
  • so your answer is that there is no advantage to AtomicLong if i just get and set it, right? obviously if i wanted to use an increment operation i would want it to be done atomically, but that's not what the question is specifying... – inor Sep 10 '15 at 16:22
0

There is no advantage as long as the primitive long is declared volatile, or if a 64 bit JVM is used. An assignment to a simple (non-volatile) long in a 32 bit JVM is not atomic, so one thread can start the assignment (some bytes moved into the long, but not all) and then another thread can read/access the long and get a corrupt value. In a 64 bit JVM the assignment and access are atomic. Similarly if you declare the long as volatile, it will be assigned/accessed atomically.

inor
  • 2,423
  • 2
  • 22
  • 39