|
HP OpenVMS Systemsask the wizard |
|
The Question is:
In a previous question (wiz_1661.html) the Wizard said
>> On Alpha, failure to use the memory barrier operators (when
>> necessary) to ensure consistent memory contents -- memory
>> barriers are used to properly control the (expected) read
>> and write reordering normally found on Alpha. The barrier
>> will block execution until all pending memory operations
>> 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).
|