Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Markus Schaaf
Date : Thu Feb 03 2005 04:00 pm

"Scott Meyers" <Usenet@aristeia.com> wrote:

> I've encountered documents (including, but not limited to, postings on this
> newsgroup) suggesting that acquire barriers and release barriers are not
> standalone entities but are instead associated with loads and stores,
> respectively.  Furthermore, making them standalone seems to change
> semantics (see below).  Yet APIs for inserting them via languages like C or
> C++ seem to deal with barriers alone -- there are no associated reads or
> writes.  (See, for example,
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrf_readwritebarrier.asp.)

It seems worth noting, that acquire and release barriers are just a variety
of memory visibility models. If you are concerned with broader aspects of
memory visibility, say, from perspective of a general purpose programming
language, it might be useful to widen the focus.

Also you may not be aware of, that Microsoft's _ReadWriteBarrier is just a
flag to the optimizer, similar to volatile. It doesn't insert any kind of
memory barrier at processor level. There are other intrinsics that do, but
these are processor specific, like inline assembly language, and surely not
intended for ordinary pragramming.

.