1. Overview
====================
Memory barriers exist to make sure the compiler and the CPU do what we intend.
-The compiler memory barreir (cmb()) (called an optimization barrier in linux)
+The compiler memory barrier (cmb()) (called an optimization barrier in linux)
prevents the compliler from reordering operations. However, CPUs can also
reorder reads and writes, in an architecture-dependent manner. In most places
with shared memory synchronization, you'll need some form of memory barriers.
When writing code that synchronizes with other threads via shared memory, we
have a variety of patterns. Most infamous is the "signal, then check if the
receiver is still listening", which is the critical part of the "check,
-signal, check again" pattern. For exmaples, look at things like
-'notif_pending' and 'can_rcv_msg'.
+signal, check again" pattern. For examples, look at things like
+'notif_pending' and when we check VC_CAN_RCV_MSG in event.c.
In these examples, "write" and "read" include things such as posting events or
checking flags (which ultimately involve writes and reads). You need to be
like read_barrier_depends() and a few other things. They also support some
non-Intel x86 clones that need wmb_f() in place of a wmb() (support out of
order writes). If this pops up, we'll deal with it.
+
+I chatted with Andrew a bit, and it turns out the following needs a barrier
+on P2 under the Alpha's memory model:
+
+ (global) int x = 0, *p = 0;
+
+ P1:
+ x = 3;
+ FENCE
+ p = &x;
+
+ P2:
+ while (p == NULL) ;
+ assert(*p == 3);
+
+As far as we can figure, you'd need some sort of 'value-speculating' hardware
+to make this an issue in practice. For now, we'll mark these spots in the code
+if we see them, but I'm not overly concerned about it.
Also note that none of these barriers deal with things like page talble walks,
page/segmentation update writes, non-temporal hints on writes, etc. glhf with