Thread.MemoryBarrier Method (System.Threading)

Switch View :

ScriptFree

.NET Framework Class Library

Thread.MemoryBarrier Method

Synchronizes memory access as follows: The processor executing the current thread cannot reorder instructions in such a way that memory accesses prior to the call to MemoryBarrier execute after memory accesses that follow the call to MemoryBarrier.

Namespace: System.Threading
Assembly: mscorlib (in mscorlib.dll)

Syntax

Visual Basic

Public Shared Sub MemoryBarrier

public static void MemoryBarrier()

Visual C++

public:
static void MemoryBarrier()

static member MemoryBarrier : unit -> unit

Remarks

MemoryBarrier is required only on multiprocessor systems with weak memory ordering (for example, a system employing multiple Intel Itanium processors).

For most purposes, the C# lock statement, the Visual Basic SyncLock statement, or the Monitor class provide easier ways to synchronize data.

Version Information

.NET Framework

Supported in: 4, 3.5, 3.0, 2.0, 1.1

.NET Framework Client Profile

Supported in: 4, 3.5 SP1

Portable Class Library

Supported in: Portable Class Library

Platforms

Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2

The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.

Reference

Thread Class

System.Threading Namespace

Community Content

_Abhishek_

Can also be used in compilation targeted for processors other than ITANIUM

We can demonstrate that memory barriers are important on ordinary Intel Core-2 and Pentium processors with the following short program. You’ll need to run it with optimizations enabled and without a debugger (in Visual Studio, select Release Mode in the solution’s configuration manager, and then start without debugging): $0 $0staticvoidMain(){ bool complete =false; vart =newThread(()=> { bool toggle =false; while(!complete) toggle =!toggle; }); t.Start(); Thread.Sleep(1000); complete =true; t.Join(); // Blocks indefinitely} $0 $0This program never terminates because the complete variable is cached in a CPU register. Inserting a call to Thread.MemoryBarrier inside the while loop (or lockingaround reading complete) fixes the error.$0 $0$0 $0an abstract from albahari's blog on threading$0 $0

abatishchev

why documentation changed?

Silverlight version of this method doc mentions: "Therefore, language compilers, the CPU, and the JIT compiler will not reorder memory operations (read or write) that appear in your program before the call to MemoryBarrier so that they occur after the call to MemoryBarrier when the program is executed. Similarly, memory accesses that appear in your program after the call will not be executed before the call."Why this text does not appear here, in .net 4 page?

abatishchev

Not needed? Really?

Not sure why I'm the first to comment on this... C# 4 In a Nutshell (terrific read by the way, highly recommended) points out that this documentation is incorrect in asserting that MemoryBarrier is requires only on multiprocessor systems with weak memory ordering. The authors point to the following code to prove their point:

static void Main()
{
    bool complete = false;
    var t = new Thread(() =>
    {
         bool toggle = false;
         while(!complete)
             toggle = !toggle;
     })
     t.Start();
    Thread.Sleep(1000);
    complete = true;
    t.Join(); // Blocks indefinitely
}

If you run this with optimizations enabled and no debugger the app will not terminate because the complete variable is cached!

FrankDeGroot

Processor reordering

@noahblu: The sample you added is about compiler optimization. Thread.MemoryBarrier() is about the processor reordering machine code instructions.