Writing of primitives to stack or heap?

Question

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!

I'd say your interviewer has misunderstood it. This sounds like nonsense. — Dawood ibn Kareem, Nov 28 '17 at 17:56
It kinda sounds like the question is about variable visibility (in the concurrency sense of the term), as described by someone who doesn't really understand it. — Kayaman, Nov 28 '17 at 18:05
Voting to close as "opinion based" because all anybody can do is offer their opinion of what the interviewer might have been thinking. — Solomon Slow, Nov 28 '17 at 18:32
[This question](https://stackoverflow.com/q/1090311) and [this question](https://stackoverflow.com/q/4633866) are related. — Dawood ibn Kareem, Nov 28 '17 at 18:37
Probably referring to [lack of visbility of updates of non-volatile variable updates](https://stackoverflow.com/questions/25425130/loop-doesnt-see-changed-value-without-a-print-statement). `long` is a bit of a red herring here. anything word-sized can fall victim to redundant read elimination, even object references. if one were to focus on the `long` then mostly historical caveats about word tearing on 32bit machines come to mind. — the8472, Nov 28 '17 at 19:12
Sometimes interviewers will ask questions like these (knowing that the question is problematic) because they want to hear you explain your understanding of the way that the process actually works. In this case, he may have been phishing for an explanation of memory access mechanisms in the Java Memory Model. — scottb, Nov 28 '17 at 20:39

Gray · Accepted Answer · 2017-11-28T19:37:56.087

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.

Even a 32-bit architecture doesn't always need multiple accesses for a `long` update. It also needs an actual 32-bit hardware bus, but even twenty years ago, most 32-bit architectures had a 64-bit memory bus. But anyway, doubling the number of accesses means a few more nanoseconds... — Holger, Nov 28 '17 at 21:13

Writing of primitives to stack or heap?

1 Answers1