On 12/9/05, David Leimbach <leimy2k@gmail.com> wrote:
I think I'd be happier with new compiler
pragmas in this case than a keyword. Then at least I KNOW that it
can be ignored and will be optionally supported by compilers on a
per-case basis.
But then again, that's also true for "inline" in C++. It's just a
suggestion, one that can be ignored. The compiler can also inline
stuff I didn't ask it to. [C99 has inline now too doesn't
it?]
The difference is that with memory barriers it's often the case that
the correctness of the algorithm depends on the placement of the
barriers. Consider writing a portable spin-lock: it's crucial that
other processors not be able to observe the lock open unless they also
observe previous memory writes in the critical section. But, in the
absence of memory barriers, many CPUs don't guarantee this.
The simple answer, of course, is to put the barriers in
non-portable lock code and use the locks to protect shared state. But
the general experience seems to be that programmers will try anything
to avoid locks, for performance reasons. Double-checked locking is the
classic example -- it's such a popular idiom that Java redefined the
meaning of "volatile" to make it work. C++ will probably do something
similar.