> It reinforces the idea of Memory Ordering as voodoo
I thought there were some very solid bits in there, like the reminder that memory barriers always come in pairs.
> it conflates compiler optimizations with memory reordering
Well, the code as written is subject to reordering both by the compiler and the CPU. The author is just being honest that this isn't a perfectly crafted example. You could make a version not subject to reordering by the compiler, either by marking variables as volatile or by inserting "compiler barriers" into the code (e.g., empty volatile asm statements). I don't think this is conflation.
> Worse, it's just not true --- while this particular example might not cause problems,
I think what happened is that you interpreted the author's statement as one about memory reordering in general on the x86 architecture, but I think the author is referring to this specific application, which makes the statement true. (The sentence you quoted is bracketed by two sentences which are more explicitly about this demo application, but it's not explicit in the sentence you quoted.)
> memory reordering is still an issue that needs to be dealt with on x86.
The article links to another post by the same author with a similar experiment demonstrating reordering on x86. The example is a lot harder to follow, though, since x86 only allows reordering of stores and loads relative to each other.
> test-driven development is probably not a good approach to writing mutexes
The experiment is to show people how reordering can happen, it has educational purpose. Thermite is a bad way to heat your home, but it's a good experiment to demonstrate exothermic reactions.
Yes, the article could be written better. But there are so few people who write any articles at all on this subject, I'm glad to be able to read it.
I agree --- definitely better to have an possibly flawed article to discuss, rather than no article at all. And as a whole, the series has lots of great information.
I thought there were some very solid bits in there, like the reminder that memory barriers always come in pairs.
> it conflates compiler optimizations with memory reordering
Well, the code as written is subject to reordering both by the compiler and the CPU. The author is just being honest that this isn't a perfectly crafted example. You could make a version not subject to reordering by the compiler, either by marking variables as volatile or by inserting "compiler barriers" into the code (e.g., empty volatile asm statements). I don't think this is conflation.
> Worse, it's just not true --- while this particular example might not cause problems,
I think what happened is that you interpreted the author's statement as one about memory reordering in general on the x86 architecture, but I think the author is referring to this specific application, which makes the statement true. (The sentence you quoted is bracketed by two sentences which are more explicitly about this demo application, but it's not explicit in the sentence you quoted.)
> memory reordering is still an issue that needs to be dealt with on x86.
The article links to another post by the same author with a similar experiment demonstrating reordering on x86. The example is a lot harder to follow, though, since x86 only allows reordering of stores and loads relative to each other.
http://preshing.com/20120515/memory-reordering-caught-in-the...
> test-driven development is probably not a good approach to writing mutexes
The experiment is to show people how reordering can happen, it has educational purpose. Thermite is a bad way to heat your home, but it's a good experiment to demonstrate exothermic reactions.
Yes, the article could be written better. But there are so few people who write any articles at all on this subject, I'm glad to be able to read it.