I was today in a work interview. On one question the interviewer asked me how much time will it take to a thread to read an integer value that another thread set? Micro seconds? Milliseconds or even a second?
He told me that it can reach even a second in the case of a long value, because "the long value is written first to the stack but the reading threads read from the heap, so the value to be read should first be copied to the heap" and for long values it can take a lot of time.
Can someone please tell me if I understood it correctly and explain a bit more on that?
Thanks!
how much time will it take to a thread to read an integer value that another thread set? Micro seconds? Milliseconds or even a second?
Depends on a lot of factors. If the question is about a volatile int versus long field then the answer typically on a modern CPU is still microseconds. It actually can be quite close to a normal read in terms of performance if the field does not have frequent accesses from other threads. However, it can be significantly more expensive depending the cost of the cache invalidation and the locking of the memory line if the variable is heavily contended. Of course, if you are accessing the field inside of a synchronized block then it depends on the lock contention between threads and what other operations are in the block.
For example, on my 4 core Mac, running 10 threads all incrementing a volatile int, they can do 1 million ++ in ~190ms. That's ~0.19 microseconds per if my math is correct. Certainly not scientific in any manner but it should give you some idea of the scale. Changing to a volatile long didn't change the numbers much but I'm running on a native 64-bit system and JVM. Again, the performance hit inside of a larger application with a lot of cached memory might get closer to milliseconds but nowhere near seconds.
For comparison, it can do AtomicInteger increments in ~1300ms and 1 million AtomicLong increments in ~1400ms. Again, these numbers are approximations in a very simple test program.
He told me that it can reach even a second in the case of a long value, because "the long value is written first to the stack but the reading threads read from the heap, so the value to be read should first be copied to the heap" and for long values it can take a lot of time.
This just does not make much sense. The only difference between an int and long is that a long can take multiple accesses depending on your runtime architecture. For example, if you are on a 32-bit architecture, it may take multiple accesses to read and update the 64-bit value. But the idea that accessing a long would take seconds just because it is double the width is not valid.
how much time will it take to a thread to read an integer value that another thread set?
As mentioned by others, if this instead is talking about when one thread will see an unsynchronized update of a variable made in another thread, the answer could certainly be seconds but that has little to do with the width of the variable and nothing to do with copying between stack and heap.