Why we need Thread.MemoryBarrier()?

by

You are going to have a very hard time reproducing this bug. In fact, I would go as far as saying you will never be able to reproduce it using the .NET Framework. The reason is because Microsoft’s implementation uses a strong memory model for writes. That means writes are treated as if they were volatile. A volatile write has lock-release semantics which means that all prior writes must be committed before the current write.

However, the ECMA specification has a weaker memory model. So it is theoretically possible that Mono or even a future version of the .NET Framework might start exhibiting the buggy behavior.

So what I am saying is that it is very unlikely that removing barriers #1 and #2 will have any impact on the behavior of the program. That, of course, is not a guarantee, but an observation based on the current implementation of the CLR only.

Removing barriers #3 and #4 will definitely have an impact. This is actually pretty easy to reproduce. Well, not this example per se, but the following code is one of the more well known demonstrations. It has to be compiled using the Release build and ran outside of the debugger. The bug is that the program does not end. You can fix the bug by placing a call to Thread.MemoryBarrier inside the while loop or by marking stop as volatile.

class Program
{
    static bool stop = false;

    public static void Main(string[] args)
    {
        var t = new Thread(() =>
        {
            Console.WriteLine("thread begin");
            bool toggle = false;
            while (!stop)
            {
                toggle = !toggle;
            }
            Console.WriteLine("thread end");
        });
        t.Start();
        Thread.Sleep(1000);
        stop = true;
        Console.WriteLine("stop = true");
        Console.WriteLine("waiting...");
        t.Join();
    }
}

The reason why some threading bugs are hard to reproduce is because the same tactics you use to simulate thread interleaving can actually fix the bug. Thread.Sleep is the most notable example because it generates memory barriers. You can verify that by placing a call inside the while loop and observing that the bug goes away.

You can see my answer here for another analysis of the example from the book you cited.

More Related Contents:

  1. Create Dynamic Threads in c# [closed]
  2. Why do I need a memory barrier?
  3. Do I need to lock or mark as volatile when accessing a simple boolean flag in C#?
  4. thread with multiple parameters
  5. Event handlers not thread safe? [duplicate]
  6. How to correctly read an Interlocked.Increment’ed int field?
  7. Thread Safe Properties in C#
  8. ConcurrentDictionary Pitfall – Are delegates factories from GetOrAdd and AddOrUpdate synchronized?
  9. Should thread-safe class have a memory barrier at the end of its constructor?
  10. Is it possible to observe a partially-constructed object from another thread?
  11. What’s wrong with using Thread.Abort()
  12. How to pass parameters to ThreadStart method in Thread?
  13. How to invoke a UI method from another thread
  14. Does a locked object stay locked if an exception occurs inside it?
  15. Benefits of using async and await keywords
  16. A reproducible example of volatile usage
  17. Difference between lock(locker) and lock(variable_which_I_am_using)
  18. What is the difference between ManualResetEvent and AutoResetEvent in .NET?
  19. Lock (Monitor) internal implementation in .NET
  20. .NET 4.0 and the dreaded OnUserPreferenceChanged Hang
  21. Advantage of using Thread.Start vs QueueUserWorkItem
  22. Reading an int that’s updated by Interlocked on other threads
  23. How to get awaitable Thread.Sleep?
  24. Thread parameters being changed
  25. Queue of async tasks with throttling which supports muti-threading
  26. ThreadStaticAttribute in ASP.NET
  27. Handling events from out-of-proc COM server in managed STA application
  28. Is int? thread safe?
  29. Starting a new thread in a foreach loop
  30. Multithreaded NamePipeServer in C#

Leave a Comment