4 ms·

Based on that reply, I am going to assume you are not familiar with how these litmus tests are written, or more generally with how hardware memory models are di

Based on that reply, I am going to assume you are not familiar with how these litmus tests are written, or more generally with how hardware memory models are discussed (hint: this is just C-like pseudocode showing the order of accesses to discuss hardware reordering so saying "what if this is cached in a register by the compiler" is a non sequitur: there isn't any compiler involved here). So I don't think I can usefully continue this branch of the conversation, sorry. That said, if you want some good reading on the topic I recommend Cambridge memory model group reference I linked above. In fact, all of the Cambridge stuff is good: they got the x86 memory model right (correctly described), even before Intel did! FWIW, the OP was spot on: this is a canonical example of a reordering the Alpha does (did) that no one else does. It comes up over and over when you talk about memory models. It's almost a meme: "that's the one that Alpha did..."

dragontamer 7y ago
My main point is that a C++ level programmer BETTER be putting memory barriers in Thread2. I guess if you're working at the system / assembly level and only using C-like pseudocode for simplicity sake, there's a different set of expectations. But I know that I've been "burned" by the compiler before moving some stuff around. Programmers have to work with not only the CPU, but also with their compiler's memory model. Its a fact that is often forgotten. Even if the CPU implements a particular memory model, the compiler has a (slightly) different one, and memory barriers or fences (or Java volatile) may still be required for proper memory ordering. ---------- I see your point that this "weakness" in DEC Alpha's memory model is probably hard for system programmers and compiler writers to figure out. But it should be noted that in C++11, the Thread2 code is still wrong without the presence of a memory barrier of some kind. (and once we add the memory barrier, mb, into Thread2, it fixes the problem at both the C++11 level AND at the DEC Alpha level)
- pizlonator 7y ago
  No. For the code in thread 2 to need a barrier in C++, you’d need your modified version of it where *p is assigned earlier. And even then you only need a compiler fence (`asm volatile (“” ::: “memory”)`). That’s a two part refutation but the first part is most important: the example only needs a barrier in C++ if you change the example as you did. If you don’t change it then from the C++ standpoint there is no earlier value that could have been cached. That arises naturally in C++ code since there’s bound to be a function boundary or lock-related fence nearby. And if there isn’t one nearby then C++ programmers love compiler fences for that. You don’t need a CPU fence for this except on Alpha.

dragontamer 7y ago

My main point is that a C++ level programmer BETTER be putting memory barriers in Thread2. I guess if you're working at the system / assembly level and only using C-like pseudocode for simplicity sake, there's a different set of expectations. But I know that I've been "burned" by the compiler before moving some stuff around. Programmers have to work with not only the CPU, but also with their compiler's memory model. Its a fact that is often forgotten. Even if the CPU implements a particular memory model, the compiler has a (slightly) different one, and memory barriers or fences (or Java volatile) may still be required for proper memory ordering. ---------- I see your point that this "weakness" in DEC Alpha's memory model is probably hard for system programmers and compiler writers to figure out. But it should be noted that in C++11, the Thread2 code is still wrong without the presence of a memory barrier of some kind. (and once we add the memory barrier, mb, into Thread2, it fixes the problem at both the C++11 level AND at the DEC Alpha level)

pizlonator 7y ago
No. For the code in thread 2 to need a barrier in C++, you’d need your modified version of it where *p is assigned earlier. And even then you only need a compiler fence (`asm volatile (“” ::: “memory”)`). That’s a two part refutation but the first part is most important: the example only needs a barrier in C++ if you change the example as you did. If you don’t change it then from the C++ standpoint there is no earlier value that could have been cached. That arises naturally in C++ code since there’s bound to be a function boundary or lock-related fence nearby. And if there isn’t one nearby then C++ programmers love compiler fences for that. You don’t need a CPU fence for this except on Alpha.