What if CPU 1 also wants to write out the same word? What if CPU 1's store buffer is waiting to
write it out? No answer. It would never happen, because that would mean that two different
threads were manipulating the same data at the same time without a mutex and that's not proper.
(If you did this anyway, the value would just get overwritten.) Problem 1 solved.
What if a global variable is in a register so the CPU doesn't see the invalidated word in cache?
This also won't happen because the compiler is not allowed to keep nonlocal data in registers
across function calls [e.g., pthread_mutex_lock()!].
Store Barriers
Problems 2 and 3 are solved with the same mechanism--store barriers. A store barrier is a
machine instruction which says[6], effectively, "flush the store buffer." The CPU will then stall
until the store buffer has been written out to main memory. On a SPARC machine, there are two
instructions, stbar and membar.
[6]
In reality it says, "Place a token here in the output buffer and prevent any future writes from
crossing this boundary." This is actually more efficient than flushing the store buffer, but harder to
explain.
Now then, when should we flush the store buffer? Whenever a CPU has changed some data that it
wants other CPUs to see. This would be shared data, of course, and shared data may be used by
other CPUs only after the first CPU has released the lock protecting it. And that's when stbar is
called--when a mutex is being released. This is done by all the synchronization variable functions,
so you will never call it yourself.
Thus, the short answer to all the problems above is, "Protect shared data with a mutex."
Bus Architectures
The design of the main memory bus does not have much effect on how we write MT programs
specifically, but it does have enormous influence over how fast our programs run, and for high-
performance programs we must pay it respect. Depending on the specific program, anywhere from
Search WWH :
