0

I'm learning multi-thread programming.

But I'm confused with some words that "memory reordering" and "instruction reordering".

My question is that is "memory reordering" equivalent to "instruction reordering"?

If not what's the difference between each.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
梁雨生
  • 385
  • 3
  • 16
  • I have never heard of "memory reordering". Please tell us (ideally show us) where you found that phraseology. (My guess is that it actually says something a bit different ... or that you are seeing a mistranslation ...) Literally, memory cannot be reordered, which is why I am doubtful of what you think you have read. – Stephen C Jan 13 '21 at 06:04
  • 1
    @StephenC: It's fairly standard usage I think, meaning reordering of memory *accesses*, as observed by other threads / cores. Stack overflow even has a [tag:memory-order] tag (currently a synonym of [memory-barriers] instead of the other way around, which is unfortunate because barriers are just one way of controlling order). But anyway, it's the kind of thing that a [tag:memory-model] has rules about the allowed orderings. – Peter Cordes Jan 13 '21 at 07:50
  • 1
    Related: [Are loads and stores the only instructions that gets reordered?](https://stackoverflow.com/q/50494658) and [Can memory store be reordered really, in an OoOE processor?](https://stackoverflow.com/q/25329348) – Peter Cordes Jan 13 '21 at 07:59
  • 1
    Also [Regarding instruction ordering in executions of cache-miss loads before cache-hit stores on x86](https://stackoverflow.com/q/56070123) describes some memory-reordering that can happen on in-order exec CPUs. [Can a speculatively executed CPU branch contain opcodes that access RAM?](https://stackoverflow.com/q/64141366) covers what a store buffer does (and how it naturally allows StoreLoad reordering even on in-order CPUs) – Peter Cordes Jan 13 '21 at 08:07
  • 1
    [Does an x86 CPU reorder instructions?](https://stackoverflow.com/q/50307693) is good, and describes some of the mechanisms. http://www.lighterra.com/papers/modernmicroprocessors/ is a very good guide to CPU architecture basics including OoO exec. Focusing primarily on a single core, not on what other cores can observe in memory. – Peter Cordes Jan 13 '21 at 08:07
  • 1
    Ah, finally found a good duplicate where the answer starts with "memory ordering is not the same thing as out of order execution. It happens even on in-order pipelined CPUs.". (And it happens to be one I wrote, and has good links to more info.) I knew I'd written answers to questions like this before, but took a while to dig one up! – Peter Cordes Jan 13 '21 at 08:10
  • 1
    @PeterCordes Thanks for your replies, after reading these article you suggested, my understanding is that the instruction reordering is one of the causes of the memory reordering but they are not the same thing. Some other causes can cause memory reordering such as store buffer and invalidate queue which depends on the cache architecture. And To ensure the order of the execution and visibility, we need the memory barrier or fence. – 梁雨生 Jan 13 '21 at 14:18
  • @梁雨生: Yes, good summary, except visibility happens on its own, regardless of barriers. (If we're talking about asm, not C where a compiler *can* maybe sink a store out of an infinite loop). You only need a barrier if you want to block this thread's later memory operations until after earlier ones have happened (loads) / become visible (stores). CPUs always try to commit their store buffer to L1d$ as quickly as possible to make space for later stores; the store buffer itself is not a *cache*. – Peter Cordes Jan 13 '21 at 14:23

0 Answers0