4

Are machine word size (or smaller) writes serialized? Only one native opcode is needed to copy register content to RAM.

eleven81
  • 6,301
  • 11
  • 37
  • 48
Jacek Ławrynowicz
  • 2,670
  • 2
  • 23
  • 23

6 Answers6

7

Writing data to RAM is atomic. If two CPUs try to write to the same location at the same time, the memory controller will decide on some order for the writes. While one CPU is writing to memory, the other CPU will stall for as many cycles as necessary until the first write is completed; then it will overwrite its value. This is what's known as a race condition.

Writes that are smaller than the native word size are not atomic -- in that case, the CPU must read the old memory value into a register, write the new bytes into the register, and then write that new value back to memory.

You should never have code that depends on this -- if you have multiple CPUs that are trying to simultaneously write to the same memory location, you're doing something wrong.

Another important consideration is the cache coherency problem. Each CPU has its own cache. If a CPU writes data to its cache, the other CPUs need to be made aware of the change to that data value if they want to read it.

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589
  • what about read operation? will again the memory controller will decide who will read first or both can read at the same time? – Vicky Gupta Apr 30 '20 at 07:29
  • Note that the memory controller(s) only matter when eventually evicting dirty cache lines. CPU cores can only write to a cache line in the first place after getting exclusive ownership ([MESI](https://en.wikipedia.org/wiki/MESI_protocol)). CPUs always maintain cache coherency, so contention between cores means they have to wait for acknowledgement of their RFO (Read For Ownership) before committing a store from the store buffer to L1d cache. – Peter Cordes Feb 11 '22 at 00:40
  • Also, narrow stores may take an extra cycle to commit to cache (common on most non-x86 ISAs), but that's *not* visibly non-atomic, unlike if done by software. See [Can modern x86 hardware not store a single byte to memory?](https://stackoverflow.com/q/46721075) which debunks that claim for all ISAs with byte stores, not just x86. – Peter Cordes Feb 11 '22 at 00:42
2

There is nothing that prevents you from doing this on a low level. RAM writes are atomic however, so memory controller will execute 2 seemingly simulateneous writes from cores sequentially.

xelurg
  • 4,294
  • 9
  • 35
  • 37
  • Actually, that only goes for cores on the same CPU, not for separate CPUs, right? – T.E.D. Feb 05 '09 at 17:40
  • AFAIR, it depends on the implementation. Memory contoller is ultimately what decides how to write data to RAM. CPU just issues command to it and provides data via data bus and address via address bus. – xelurg Feb 05 '09 at 17:46
  • @T.E.D.: Yes, separate memory controllers (or channels of the same controller) operate in parallel. This question asks about "The same memory location" being written from multiple cores, and any given location will be on one specific DIMM. (Unless we're talking about a misaligned multi-byte thing that's split across two cache lines). – Peter Cordes Feb 11 '22 at 00:30
0

Two CPU's may issue the command at the same time, but doesn't the RAM controller have to process each command it receives individually? So, maybe to the CPU's it is simultaneous, but the RAM controller will determine whose command is processed first.

Zachery Delafosse
  • 312
  • 1
  • 10
0

They shouldn't because the resulting RAM content would be unspecified if different values were written.

Zach Scrivena
  • 29,073
  • 11
  • 63
  • 73
  • in fact it will be the value of the latest data register submitted to the write pipeline in memory controller – xelurg Feb 05 '09 at 17:36
  • @xelurg: I agree. But in that case the actual writes are not simultaneous (since they have to be pipelined). In other words, it wouldn't make sense to have two independent write pipelines for the same memory. – Zach Scrivena Feb 05 '09 at 17:46
0

Isn't that native opcode more likely to be writing to the on-CPU cache than directly to RAM?

ChrisW
  • 54,973
  • 13
  • 116
  • 224
  • Aren't CPU caches write-through? Does it matter in context of atomicity? – Jacek Ławrynowicz Feb 05 '09 at 17:41
  • I think you're referring to the micro-code, which is set of signal levels applied to elements within a CPU... opcode is a higher level - it can operate on various set of elements, including memory and I/O port. http://en.wikipedia.org/wiki/Opcode – xelurg Feb 05 '09 at 17:42
  • forgot to include a link to microcode blurb :) http://en.wikipedia.org/wiki/Microcode – xelurg Feb 05 '09 at 17:47
  • yabcok: I meant ChrisW is referring to microcode when saying that opcode is more likely to write to cache rather then RAM – xelurg Feb 05 '09 at 17:50
  • "Aren't CPU caches write-through?" Googling suggests that writes can be "write-back" instead of "write-through", and that some (Intel) CPUs use a hybrid "write-back" and "write-through". Opcodes aren't as 1-to-1 as they used to be with what's happening at the hardware level. – ChrisW Feb 05 '09 at 17:57
0

They can try, but hardware will be the ultimate determinant of what happens.

MSN
  • 53,214
  • 7
  • 75
  • 105
  • It's still up to the hardware, and by hardware I mean how the CPU interfaces with memory. – MSN Feb 05 '09 at 19:44