c-smile wrote:

[]

> Ты пойми, никакого формального же описания "барьеров" в документации VC++ просто нет. Собственно как и ни в каком другом компиляторе.
> Единственное что есть это volatile.

Нашел немного.

http://www.microsoft.com/whdc/driver/kernel/MP_issues.mspx

[q]The volatile Keyword

The volatile keyword in C indicates that the value associated with a variable can be changed by something outside the control of the current thread.
The compiler reads the value of a volatile variable from memory each time the variable is referenced and writes the value of the variable to memory each time it is assigned. Without the volatile keyword, the compiler might optimize access to the variable by combining read or write operations or by reordering references to the variable in code.
...
Details of how to implement the volatile keyword are not specified in the ANSI language standards, but are left to compiler developers. Therefore, implementations may vary from compiler to compiler. Never assume that every C compiler—or even every version of a single manufacturer’s C compiler—implements volatile in the same way.
The Microsoft C compiler generates code for each assignment to or reference of a volatile variable, even if the code appears to have no effect. If you declare a variable as volatile, the compiler considers it volatile for the lifetime of the variable. You can also cast a single reference as volatile; in this case, the compiler is guaranteed to generate code for that reference only.
...
If you look at the sample drivers shipped with the Windows DDK, you will see that volatile appears infrequently. In general, volatile is of limited use in driver code for the following reasons:
• Using volatile prevents optimization only of the volatile variables themselves. It does not prevent optimizations of nonvolatile variables relative to volatile variables. For example, a write to a nonvolatile variable that precedes a read from a volatile variable in the source code might be moved to execute after the read.
• Using volatile does not prevent the reordering of instructions by the processor hardware.
• Using volatile correctly is not enough on a multiprocessor system to guarantee that all CPUs see memory accesses in the same order.
Windows synchronization mechanisms are more useful in preventing all these potential problems.
...
Windows Synchronization Mechanisms
...
• The InterlockedXxx routines perform common arithmetic and logical operations atomically, ensuring correct results on multiprocessor systems. Whenever possible, drivers should use these routines because they are fast. Most of them are native processor instructions that are implemented inline by the compiler and can be called at any IRQL.
...
Memory Barriers and Hardware Reordering
In certain situations on some hardware architectures, the processor can reorder read and write instructions. Furthermore, on multiprocessor architectures, the sequence in which read and write operations are executed can appear different from the perspective of different processors. To prevent hardware reordering, the executable code must contain memory barriers.
If your driver uses only the standard Windows locking mechanisms, you don’t need to be concerned about hardware reordering or memory barriers. All of the standard Windows locking mechanisms (spin locks, mutexes, kernel events, and resources managed by the executive resource package) protect against processor reordering by inserting memory barriers where required in executable code. So do the InterlockedXxx and ExInterlockedXxx functions.
This feature is an important reason to use the Windows mechanisms and to avoid creating your own locks. As a general rule, a driver should never create its own locks except in the rare situations where it has special requirements that make using the Windows mechanisms impractical or undesirable. Driver-created locks must insert memory barriers to prevent hardware reordering in certain conditions. These conditions can be difficult to detect and the problems resulting from them can be extremely tricky to debug.
...
[/q]

И на закуску сладенькое фанатам volatile:

Memory Barrier Semantics
A memory barrier is a processor instruction that preserves the ordering of read and/or write operations from the perspective of any other processor. Memory barriers include processor instructions with acquire, release, and fence semantics. These semantics describe the order in which results of an operation become visible.
• Acquire semantics mean that the results of the operation are visible before the results of any operation that appears after it in code.
• Release semantics mean that the results of the operation are visible after the results of any operation that appears before it in code.
• Fence semantics combine acquire and release semantics. The results of an operation with fence semantics are visible before those of any operation that appears after it in code and after those of any operation that appears before it.
...
On x86 and x64-based hardware (including AMD64 and the Intel Extended Memory 64 Technology), the InterlockedXxx and ExInterlockedXxx functions have both acquire and release semantics by default. The Intel Itanium architecture, however, can execute operations that have either acquire or release semantics (and not both) faster than those that have both. On Windows “Longhorn,” Microsoft plans to provide versions of the InterlockedXxx and ExInterlockedXxx functions that support either acquire or release semantics.
In addition, Microsoft CL 14.0.0 and later versions tighten the restrictions on the types of reordering that can occur around volatile variables. In these compilers, reads from volatile locations are treated as acquires and writes to volatile locations are treated as releases on hardware architectures that support these semantics.

--
Maxim Yegorushkin