C#中使用Monitor类、Lock和Mutex类来同步多线程的执行-CSDN博客

http://blog.csdn.net/tjvictor/archive/2007/01/20/1488290.aspx

C#中使用Monitor类、Lock和Mutex类来同步多线程的执行
        在多线程中，为了使数据保持一致性必须要对数据或是访问数据的函数加锁，在数据库中这是很常见的，但是在程序中由于大部分都是单线程的程序，所以没有加锁的必要，但是在多线程中，为了保持数据的同步，一定要加锁，好在Framework中已经为我们提供了三个加锁的机制，分别是Monitor类、Lock关键字和Mutex类。
        其中Lock关键词用法比较简单，Monitor类和Lock的用法差不多。这两个都是锁定数据或是锁定被调用的函数。而Mutex则多用于锁定多线程间的同步调用。简单的说，Monitor和Lock多用于锁定被调用端，而Mutex则多用锁定调用端。
例如下面程序：由于这种程序都是毫秒级的，所以运行下面的程序可能在不同的机器上有不同的结果，在同一台机器上不同时刻运行也有不同的结果，我的测试环境为vs2005, windowsXp , CPU3.0 , 1 G monery。
        程序中有两个线程thread1、thread2和一个TestFunc函数，TestFunc会打印出调用它的线程名和调用的时间(mm级的)，两个线程分别以30mm和100mm来调用TestFunc这个函数。TestFunc执行的时间为50mm。程序如下：
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
namespace MonitorLockMutex
{
    class Program
    {
        #region variable
        Thread thread1 = null;
        Thread thread2 = null;
        Mutex mutex = null;
        #endregion
        static void Main(string[] args)
        {
            Program p = new Program();
            p.RunThread();
            Console.ReadLine();
        }
        public Program()
        {
            mutex = new Mutex();
            thread1 = new Thread(new ThreadStart(thread1Func));
            thread2 = new Thread(new ThreadStart(thread2Func));
        }
        public void RunThread()
        {
            thread1.Start();
            thread2.Start();
        }
        private void thread1Func()
        {
            for (int count = 0; count < 10; count++)
            {
                TestFunc("Thread1 have run " + count.ToString() + " times");
                Thread.Sleep(30);
            }
        }
        private void thread2Func()
        {
            for (int count = 0; count < 10; count++)
            {
                TestFunc("Thread2 have run " + count.ToString() + " times");
                Thread.Sleep(100);
            }
        }
        private void TestFunc(string str)
        {
            Console.WriteLine("{0} {1}", str, System.DateTime.Now.Millisecond.ToString());
            Thread.Sleep(50);
        }
    }
}
运行结果如下：

        可以看出如果不加锁的话，这两个线程基本上是按照各自的时间间隔+TestFunc的执行时间(50mm)对TestFunc函数进行读取。因为线程在开始时需要分配内存，所以第0次的调用不准确，从第1~9次的调用可以看出，thread1的执行间隔约是80mm，thread2的执行间隔约是150mm。
现在将TestFunc修改如下：
private void TestFunc(string str)
{
   lock (this)
   {
      Console.WriteLine("{0} {1}", str, System.DateTime.Now.Millisecond.ToString());
      Thread.Sleep(50);
   }
}
或者是用Monitor也是一样的，如下：
private void TestFunc(string str)
{
      Monitor.Enter(this);
      Console.WriteLine("{0} {1}", str, System.DateTime.Now.Millisecond.ToString());
      Thread.Sleep(50);
      Monitor.Exit(this);
}
其中Enter和Exit都是Monitor中的静态方法。
运行Lock结果如下：

        让我们分析一下结果，同样从第1次开始。相同线程间的调用时间间隔为线程执行时间+TestFunc调用时间，不同线程间的调用时间间隔为TestFunc调用时间。例如：连续两次调用thread1之间的时间间隔约为30+50=80;连续两次调用thread2之间的时间间隔约为100+50=150mm。调用thread1和thread2之间的时间间隔为50mm。因为TestFunc被lock住了，所以一个thread调用TestFunc后，当其它的线程也同时调用TestFunc时，后来的线程即进被排到等待队列中等待，直到拥有访问权的线程释放这个资源为止。
        这就是锁定被调用函数的特性，即只能保证每次被一个线程调用，线程优先级高的调用的次数就多，低的就少，这就是所谓的强占式。
        下面让我们看看Mutex类的使用方法，以及与Monitor和Lock的区别。
将代码修改如下：
        private void thread1Func()
        {
            for (int count = 0; count < 10; count++)
            {
                mutex.WaitOne();
                TestFunc("Thread1 have run " + count.ToString() + " times");
                mutex.ReleaseMutex();
            }
        }

        private void thread2Func()
        {
            for (int count = 0; count < 10; count++)
            {
                mutex.WaitOne();
                TestFunc("Thread2 have run " + count.ToString() + " times");
                mutex.ReleaseMutex();
            }
        }

        private void TestFunc(string str)
        {
            Console.WriteLine("{0} {1}", str, System.DateTime.Now.Millisecond.ToString());
            Thread.Sleep(50);
        }
运行结果如下：

        可以看出，Mutex只能互斥线程间的调用，但是不能互斥本线程的重复调用，即thread1中waitOne()只对thread2中的waitOne()起到互斥的作用，但是thread1并不受本wainOne()的影响，可以调用多次，只是在调用结束后调用相同次数的ReleaseMutex()就可以了。
        那么如何使线程按照调用顺序来依次执行呢？其实把lock和Mutex结合起来使用就可以了，改代码如下：
        private void thread1Func()
        {
            for (int count = 0; count < 10; count++)
            {
                lock (this)
                {
                    mutex.WaitOne();
                    TestFunc("Thread1 have run " + count.ToString() + " times");
                    mutex.ReleaseMutex();
                }
            }
        }

        private void thread2Func()
        {
            for (int count = 0; count < 10; count++)
            {
                lock (this)
                {
                    mutex.WaitOne();
                    TestFunc("Thread2 have run " + count.ToString() + " times");
                    mutex.ReleaseMutex();
                }
            }
        }

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tjvictor/archive/2007/01/20/1488290.aspx

1）只有共享资源才需要锁定
只有可以被多线程访问的共享资源才需要考虑锁定，比如静态变量，再比如某些缓存中的值，而属于线程内部的变量不需要锁定。

2）多使用lock,少用Mutex
如果你一定要使用锁定，请尽量不要使用内核模块的锁定机制，比如.NET的Mutex，Semaphore，AutoResetEvent和 ManuResetEvent，使用这样的机制涉及到了系统在用户模式和内核模式间的切换，性能差很多，但是他们的优点是可以跨进程同步线程，所以应该清楚的了解到他们的不同和适用范围。

note: from envykok

Mutex是跨进程的，因此我们可以在同一台机器甚至远程的机器上的多个进程上使用同一个互斥体。尽管Mutex也可以实现进程内的线程同步，而且功能也更强大，但这种情况下，还是推荐使用Monitor，因为Mutex类是win32封装的，所以它所需要的互操作转换更耗资源

3）了解你的程序是怎么运行的
实际上在web开发中大多数逻辑都是在单个线程中展开的，一个请求都会在一个单独的线程中处理，其中的大部分变量都是属于这个线程的，根本没有必要考虑锁定，当然对于ASP.NET中的Application对象中的数据，我们就要考虑加锁了。

Mutex 有两种类型：未命名的局部 mutex e.g. : Private Shared mut As New Mutex()
和已命名的系统 mutex e.g.: Private Shared mut As New Mutex(false,"nameofmutex")

局部互斥体仅存在于您的进程内。您的进程中任何引用表示 mutex 的 Mutex 对象的线程都可以使用它。每个未命名的 Mutex 对象都表示一个单独的局部 mutex。

已命名的系统互斥体在整个操作系统中都可见，可用于同步进程活动。您可以使用接受名称的构造函数创建表示已命名系统 mutex 的 Mutex 对象。同时也可以创建操作系统对象，或者它在创建 Mutex 对象之前就已存在。您可以创建多个 Mutex 对象来表示同一个已命名的系统互斥体，也可以使用 OpenExisting 方法打开现有的已命名系统互斥体。

http://stackoverflow.com/questions/1164038/monitor-vs-mutex-in-c

http://stackoverflow.com/questions/301160/what-are-the-differences-between-various-threading-synchronization-options-in-c

Monitors

lock(obj) is implemented internally using a Monitor. You should prefer lock(obj) because it prevents you from goofing up like forgetting the cleanup procedure. It 'idiot-proof's the Monitor construct if you will. Using Monitor is generally preferred over mutexes, because monitors were designed specifically for the .NET Framework and therefore make better use of resources.

Using a lock or monitor is useful for preventing the simultaneous execution of thread-sensitive blocks of code, but these constructs do not allow one thread to communicate an event to another. This requires synchronization events, which are objects that have one of two states, signaled and un-signaled, that can be used to activate and suspend threads. Mutex, Semaphores are OS-level concepts.

e.g with a named mutex you could synchronize across multiple (managed) exes (ensuring that only one instance of your application is running on the machine.)

Mu tex:

Unlike monitors, however, a mutex can be used to synchronize threads across processes. When used for inter-process synchronization, a mutex is called a named mutex because it is to be used in another application, and therefore it cannot be shared by means of a global or static variable. It must be given a name so that both applications can access the same mutex object. In contrast, the Mutex class is a wrapper to a Win32 construct. While it is more powerful than a monitor, a mutex requires interop transitions that are more computationally expensive than those required by the Monitor class.

http://msdn.microsoft.com/en-us/library/ms173179%28VS.80%29.aspx

Code:

object obj = x; System.Threading.Monitor.Enter(obj); try { … } finally { System.Threading.Monitor.Exit(obj); }

That Mutex (because it has a name) will stop any process on the same machine accessing it as well, whereas lock will only stop other threads in the same process.

By the way, catch {} is absolutely the wrong thing to use in that scenario. You should use finally { /* release mutex */ } . They are very different. The catch will swallow far more kinds of exception than it should, and will also cause nested finally handlers to execute in response to low-level exceptions such as memory corruption, access violation, etc. So instead of:

try



{


    
// something



}



catch



{}





// cleanup

You should have:

try



{


    
// something



}



finally



{


    
// cleanup



}

And if there are specific exceptions you can recover from, you could catch them:

try



{


    
// something



}



catch
 
(
DatabaseConfigurationError
 x
)



{


    
// tell the user to configure the database properly



}



finally



{


    
// cleanup



}