  Shared memory and Alpha memory barriers (MB)? 
 The Question is:
 
In a previous question (wiz_1661.html) the Wizard said
 
&gt;&gt; On Alpha, failure to use the memory barrier operators (when
&gt;&gt; necessary) to ensure consistent memory contents -- memory
&gt;&gt; barriers are used to properly control the (expected) read
&gt;&gt; and write reordering normally found on Alpha.  The barrier
&gt;&gt; will block execution until all pending memory operations
&gt;&gt; have completed.
 
Could you please explain Memory Barriers a little further
 
1 - What Are They ... User Mode and/or Elevated Mode ?
2 - When to use them
3 - How to use them, ie what function calls
4 - A code example, showing how code would
    NOT or probably NOT work, follwed by same code,
    with correct usage of memory barrier, so
    code will work.
 
 
Thank You
 
 
Fred Bloggs
 
 
 The Answer is :
 
  The OpenVMS Wizard would strongly encourage you to read the information
  on memory barriers present in the Alpha Architecture Handbook.
 
  You can order this document, or you can download it from a pointer
  in the OpenVMS FAQ.
 
  A memory barrier is an Alpha instruction, and this instruction can
  be used in any processor privilege mode and at any time.
 
  There are two general types of memory barrier, those that involve
  synchornizing completion of loads and stores to memory, and the IMB
  PALcode routine that must be used after modifications are made to the
  instruction stream.  (The IMB PALcode call is logically equivilent to
  the execution of the REI instruction required on VAX systems after an
  instruction stream modification.)
 
  You must use memory barriers when you want to guarantee the ordering
  of completion of memory operations.  The Alpha Architecture permits
  the processor to re-order loads and stores; thus memory may be read or
  written in a different order than that specified by the programmer.
  This reordering is done to improve system performance, but it can
  occasionally also introduce undesirable side effects.  The memory
  barrier instructions (MB and WMB) permit the programmer to explicitly
  synchronize the continued execution of the application with the
  necessary completion of all memory load and store operations currently
  outstanding.  Using other terminology, a memory barrier is a
  synchronization point for memory.
 
  For a general example of the need for memory barriers, assume the
  following -- be aware of the distinction made between processes and
  processors in this discussion.  Assume you have a shared memory global
  section containing a data structure.  This data structure is protected
  by a lock cell that is stored in the shared memory.  A process must
  acquire ownership of the data structure by setting the lock cell to a
  non-zero value (say, to the Process Id of the accessor) when it plans
  to write or update the contents of the data structure.  All other
  processes will be prevented from accessing the structure when it is
  found locked, and will spin or otherwise defer access waiting for the
  lock cell to be cleared.  Once the process holding the lock completes
  the necessary writes or modifications, it then clears the value in the
  lock cell by writing a zero back to the lock cell location.
 
  The Alpha processor -- because it may re-order loads and stores -- may
  choose to reorder the operations and write the lock cell location before
  it performs the updates on the contents of the data structure.  Because
  of this reordering, other processes on other processors will then see the
  lock cell become zero and then (one process can) acquire the lock and may
  then read the same structure field(s) before the first processor has
  written the updated data to the field(s), thereby acquiring erronous
  (stale) data.  While the programmer wrote the data to memory in the
  appopriate order, the Alpha processor reordered the memory access(es).
 
  The mechanism used to control this involves the execution of a MB
  instruction after the update to the structure field and prior to
  releasing the lock, and inserting another MB after releasing the lock.
  This will guarantee the ordering of the writes, and will ensures that
  all processes will see the correct data.
 
  Memory barriers are also used to control how an Alpha processor
  aggregates memory writes -- an Alpha processor may cache a memory write
  for some relatively long interval, before actually completing the write
  to memory.  Until the data is written to memory, it is not visible to
  other Alpha processors in the system.  Most of the time, this behaviour
  is entirely benign -- it often improves performance by permitting a
  processor to aggregate multiple write operations into a single memory
  bus transaction, caching and then sending multiple write operations out
  to memory together.  There are cases where a programmer wants a write
  visible immediately, and the MB and the WMB instruction can be used to
  accomplish this.
 
  PALcode calls will contain memory barriers when appropriate, but an
  OpenVMS programmer should not assume that any particular intervening
  PALcode or OpenVMS system service call will contain a memory barrier
  operation.  If a memory barrier is required for a particular series of
  memory operations, explicitly include the memory barrier in the code.
 
  How you write code that uses memory barriers depends on the language.
  Using Compaq C for OpenVMS Alpha, you can use the __MB builtin and the
  asm() directive.  Please see the Compaq C User's Guide for OpenVMS Systems
  for additional details, or the user's guide for your particular language.
  The OpenVMS Alpha Macro32 compiler provides various built-ins, including
  the EVAX_IMB built-in.
 
  Examples of using memory barriers are included in the Alpha Architecture
  Handbook, and additional information on memory barriers is also present
  in the OpenVMS manual set.  Please see these documents for additional
  details.
 
  The OpenVMS Wizard will leave the question of how to reliably deal with
  bitlocks, and how to spin appropriately, for topic (6984).
 
 
 
 Answer written or last revised on  31-AUG-2001 
