4

I am copying the text for that figure from the original paper, Memory Barriers: a Hardware View for Software Hackers.

Table 4 shows three code fragments, executed concurrently by CPUs 0, 1, and 2. All variables are initially zero.

Note that neither CPU 1 nor CPU 2 can proceed to line 5 until they see CPU 0’s assignment to “b” on line 3. Once CPU 1 and 2 have executed their memory barriers on line 4, they are both guaranteed to see all assignments by CPU 0 preceding its memory barrier on line 2. Similarly, CPU 0’s memory barrier on line 8 pairs with those of CPUs 1 and 2 on line 4, so that CPU 0 will not execute the assignment to “e” on line 9 until after its assignment to “a” is visible to both of the other CPUs. Therefore, CPU 2’s assertion on line 9 is guaranteed not to fire.

enter image description here

To me, Line 6-9 on CPU0 seems unnecessary at all, because the memory barrier on Line 2 for CPU 0 and memory barrier on Line 4 for CPU 1&2 guarantees that the effect of b=1 is picked up, and all stores before as well, aka a=1. Then, the assert e == 0 || a == 1 succeeds always.

I don't know if I overlooked anything. Any clarification is appreciated.

Community
  • 1
  • 1
Albert Netymk
  • 1,102
  • 8
  • 24

1 Answers1

5

Leaving lines 6-9 out of CPU 0 would definitely prevent the assert() from firing. Then again, so would removing all the code other than the assert, given that e is initialized to zero. However, both modifications are unhelpful. Instead, the key point of the assertion is the question "Is it possible for CPU 2 to see the state e==1&&a==0 at the end of its execution?" Looking at it this way should force you to think in terms of what values propagate where in what order.

But the main thing you overlooked is that this paper is extremely old, and there has been a huge amount of progress in understanding and formalizing memory ordering since then. I am in the process of adding a new memory-ordering chapter to Is Parallel Programming Hard, And, If So, What Can You Do About It? In the meantime, the pair of LWN articles here and here may be helpful.

Or if you want to see the current state of the book, git clone git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/perfbook.git.

user339589
  • 86
  • 2