Lockless algorithms for mere mortals

memory-barriers.txt can look like scientific paper to a layman indeed.

> A much simpler version could be something like: Whenever two memory accesses need to become visible to other CPUs
> in a particular order, a barrier is required between them both in code which writes to and code which reads from memory.

This can lead to cargo-cultish practices, people remembering 1 rule which doesn't quite extend to even simplest
complications -- what to do with 3 accesses.

I gave set of Linux lectures (including memory barriers!) and naturally had to do the exercises myself.

The picture with 2 cpus, 1 memory and the case on line 150 (2 cpus, 2 variables) is absolutely required
for understanding what's going on. It is like solving ax^2+bx+c=0. Do it from the beginning to the end once.
(Doesn't work and explain order 5 case, though).

There are 24 cases indeed and you _should_ write them all down and write all the outcomes.
There will be 4.

Now add one barrier, cross the cases which became impossible, there will be still 4.

Then add second pairing barrier, and there will be 3. This explains why 1 barrier is not enough.

This also explains why barriers are actually necessary -- to reduce the set of observable outcomes.

> A little "premature optimization is the root of all evil" also applies here: Start simple, make it more complicated when and
> if this becomes necessary.

Documentation/memory-barriers.txt could do better by moving "Device" down and "data dependency" to the bottom.
And there is "compiler barrier" section" in the document about memory barriers, OK.