long and double read and write operation are not atomic because of their size more than cpu word size.
So could I get atomic read and write operation of long and double if I have 64 bit machine?
Asked
Active
Viewed 1,747 times
7
-
Maybe synchronized block is that you are looking for? – damgad Apr 16 '14 at 21:55
-
i know how to get ride of this with synchronized block or volatile but i was want to know if the 64 bit machine architectural guarantee atomicity for me – Antwan Apr 16 '14 at 22:02
2 Answers
11
so could i get atomic read and write operation of long and double if i have 64 bit machine ?
The answer is "maybe". The answer depends on the JVM implementation as well as the machine architecture. To quote from the Java Language definition 17.7:
Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32-bit values. For efficiency's sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and double values atomically or in two parts.
Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.
Here's a great page about Ensure atomicity when reading and writing 64-bit values.
-
@Gray lets suppose i have a 64bits JVM, will double/long operation be atomic then (all 64bits are read in one step)?? – roottraveller Jun 15 '17 at 07:02
-
-
@Gray thats totally understandable through a 64bits reading will increse performance. should not the architecture be changed or modified? – roottraveller Jun 16 '17 at 05:19
2
Directly answering the question, using volatile or AtomicLong will make actual read/write atomic.
However, excluding some specific cases these are often insufficient by themselves - that is they ensure that the read/write itself is atomic, but do not guarantee that the program is thread-safe.
To create truly atomic usage, larger atomic contexts must generally be established. In the most basic form this is done with synchronized.
Community
- 1
- 1
user2864740
- 60,010
- 15
- 145
- 220
-
read and write itself atomic even if the data type was larger than cpu words? – Antwan Apr 16 '14 at 22:05
-
2@Tony The JLS *guarantees* [that all value read/writes (except for double/long) are atomic](http://stackoverflow.com/a/4756578/2864740) - but it doesn't say that double/long *aren't* atomic on any particular machine/implementation. The usage of `volatile` *guarantees* that double/long will also be read/written atomically (at the machine level which "avoids tearing"). Likewise, `AtomicLong` is guaranteed to expose atomic operations (at the machine level). – user2864740 Apr 16 '14 at 22:09
-
@nosid I'm not sure about "misleading", but it was needless baggage :) I've removed it, thanks for the feedback. – user2864740 Apr 16 '14 at 22:15
-
-
`synchronized` blocks do not guarantee atomic-ness. They guarantee mutex and memory synchronization. – Gray Dec 11 '15 at 16:49
-
@Gray: From the perspective of a thread that respect a mutex, everything inside a critical section in another thread happens as an atomic transaction. (Do any JVMs use x86 hardware transactional memory for this, or a mutex with lock ellision? https://www.realworldtech.com/haswell-tm/) – Peter Cordes Apr 25 '18 at 10:47
-
This is not my understanding @PeterCordes in terms of how the JVM works. There is nothing that says that a thread in the middle of a synchronized block _can't_ flush it's memory, it just saying that it's not guaranteed. A thread could get swapped off of a processor for example causing it's pages to the written to main memory. Or another thread could get swapped in meaning that it gets it's memory refreshed. Locking or unlocking mutex and crossing memory barriers have guarantees around publishing of data but there are no guarantees around memory _not_ being published at other times. – Gray Apr 25 '18 at 13:05
-
Except for pure store or pure load where all bits can be changed physically simultaneously, atomicity is always with respect to an observer. `lock add [rdi], 1` doesn't happen instantaneously, and you could in theory observe it happening with a logic analyzer or oscilloscope, but it's atomic with respect to any hardware observers. My point in the last comment was that anything you do inside a critical section is atomic with respect to any software observers *that respect the mutex*. Of course you *can* ignore the mutex and load from shared data while another thread has the lock... :P – Peter Cordes Apr 25 '18 at 13:05
-
But yeah, unless you use hardware transactional memory instead of a mutex, software can violate the atomicity if you get the locking wrong. Anyway, on x86, C++ `std::atomic
` really is atomic in hardware without any locking, using `lock cmpxchg` for read-modify-write ops: [Atomic double floating point or SSE/AVX vector load/store on x86\_64](//stackoverflow.com/q/45055402). A thread getting "swapped off a processor" causing its pages to be written to main memory sounds wrong. It already is using main memory, the CPU store buffer (read-modify-write operations) are the issue. – Peter Cordes Apr 25 '18 at 13:16