支持所有权、最大进程共享锁数和临界区允许的最大进程/线程数是决定具有通用锁名的并发对象的名称/类型的三个主要因素。由于这些因素的值是二进制的(有两种状态)，我们可以将它们总结为一个3*8的类真值表。

X(支持所有权?):no(0) / yes(1) Y(#共享进程):> 1(∞)/ 1 Z (#processes/threads in CA): > 1(∞)/ 1

  X   Y   Z          Name
 --- --- --- ------------------------
  0   ∞   ∞   Semaphore              
  0   ∞   1   Binary Semaphore       
  0   1   ∞   SemaphoreSlim          
  0   1   1   Binary SemaphoreSlim(?)
  1   ∞   ∞   Recursive-Mutex(?)     
  1   ∞   1   Mutex                  
  1   1   ∞   N/A(?)                 
  1   1   1   Lock/Monitor           

请随意编辑或展开这个表，我已经把它作为一个ascii表进行编辑:)

大多数问题都可以用(i)锁，(ii)信号量来解决……，或(iii)两者的组合!正如您可能已经发现的，它们非常相似:都防止竞争条件，都有acquire()/release()操作，都导致零或多个线程被阻塞/怀疑…… 实际上，关键的区别仅仅在于它们如何锁定和解锁。

A lock (or mutex) has two states (0 or 1). It can be either unlocked or locked. They're often used to ensure only one thread enters a critical section at a time. A semaphore has many states (0, 1, 2, ...). It can be locked (state 0) or unlocked (states 1, 2, 3, ...). One or more semaphores are often used together to ensure that only one thread enters a critical section precisely when the number of units of some resource has/hasn't reached a particular value (either via counting down to that value or counting up to that value).

对于这两个锁/信号量，在原语处于状态0时试图调用acquire()会导致调用线程挂起。对于锁——获取状态为1的锁的尝试是成功的。对于信号量——尝试获取状态{1,2,3，…是成功的。

对于状态为0的锁，如果之前调用acquire()的同一个线程现在调用release，则释放成功。如果一个不同的线程尝试了这个操作，那么将由实现/库决定发生什么(通常是忽略尝试或抛出错误)。对于处于状态0的信号量，任何线程都可以调用release，并且它将成功(不管之前哪个线程使用acquire将信号量置于状态0)。

从前面的讨论中，我们可以看到锁有一个所有者的概念(唯一可以调用释放的线程是所有者)，而信号量没有所有者(任何线程都可以在信号量上调用释放)。

造成很多困惑的是，在实践中，它们是这个高级定义的许多变体。

需要考虑的重要变化:

acquire()/release()应该被称为什么?—[变化很大] 您的锁/信号量是否使用“队列”或“集”来记住等待的线程? 你的锁/信号量可以与其他进程的线程共享吗? 你的锁是“可重入的”吗?——[通常是的]。 你的锁是“阻塞/非阻塞”吗?-[通常非阻塞锁被用作阻塞锁(又名自旋锁)，导致繁忙等待]。 如何确保操作是“原子的”?

这取决于你的书/讲师/语言/图书馆/环境。 下面是一些语言是如何回答这些细节的。

C, C+ (pthreads)

A mutex is implemented via pthread_mutex_t. By default, they can't be shared with any other processes (PTHREAD_PROCESS_PRIVATE), however mutex's have an attribute called pshared. When set, so the mutex is shared between processes (PTHREAD_PROCESS_SHARED). A lock is the same thing as a mutex. A semaphore is implemented via sem_t. Similar to mutexes, semaphores can be shared between threasds of many processes or kept private to the threads of one single process. This depends on the pshared argument provided to sem_init.

python (threading.py)

A lock (threading.RLock) is mostly the same as C/C++ pthread_mutex_ts. Both are both reentrant. This means they may only be unlocked by the same thread that locked it. It is the case that sem_t semaphores, threading.Semaphore semaphores and theading.Lock locks are not reentrant -- for it is the case any thread can perform unlock the lock / down the semaphore. A mutex is the same as a lock (the term is not used often in python). A semaphore (threading.Semaphore) is mostly the same as sem_t. Although with sem_t, a queue of thread ids is used to remember the order in which threads became blocked when attempting to lock it while it is locked. When a thread unlocks a semaphore, the first thread in the queue (if there is one) is chosen to be the new owner. The thread identifier is taken off the queue and the semaphore becomes locked again. However, with threading.Semaphore, a set is used instead of a queue, so the order in which threads became blocked is not stored -- any thread in the set may be chosen to be the next owner.

Java (Java . util . concurrent)

A lock (java.util.concurrent.ReentrantLock) is mostly the same as C/C++ pthread_mutex_t's, and Python's threading.RLock in that it also implements a reentrant lock. Sharing locks between processes is harder in Java because of the JVM acting as an intermediary. If a thread tries to unlock a lock it doesn't own, an IllegalMonitorStateException is thrown. A mutex is the same as a lock (the term is not used often in Java). A semaphore (java.util.concurrent.Semaphore) is mostly the same as sem_t and threading.Semaphore. The constructor for Java semaphores accept a fairness boolean parameter that control whether to use a set (false) or a queue (true) for storing the waiting threads.

理论上，信号量经常被讨论，但在实践中，信号量的使用并不多。一个信号量只保存一个整数的状态，所以它通常是相当不灵活的，并且需要同时使用许多个，这导致理解代码的困难。此外，任何线程都可以释放信号量的事实有时是不希望看到的。取而代之的是更多面向对象/高级同步原语/抽象，如“条件变量”和“监视器”。

我会用一些例子来解释:

Lock:使用Lock的一个例子是将项目(必须有唯一键)添加到共享字典中。 锁将确保当另一个线程(处于临界区)已经通过检查并正在添加项时，一个线程不会进入检查字典中是否存在项的代码机制。如果另一个线程试图输入一个锁定的代码，它将等待(被阻塞)，直到对象被释放。

private static readonly Object obj = new Object();

lock (obj) //after object is locked no thread can come in and insert item into dictionary on a different thread right before other thread passed the check...
{
    if (!sharedDict.ContainsKey(key))
    {
        sharedDict.Add(item);
    }
}

信号量: 假设您有一个连接池，那么单个线程可以通过等待信号量获得连接来在池中保留一个元素。然后它使用连接，工作完成后通过释放信号量来释放连接。

我喜欢的代码示例是@Patric给出的一个bouncer -在这里:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace TheNightclub
{
    public class Program
    {
        public static Semaphore Bouncer { get; set; }

        public static void Main(string[] args)
        {
            // Create the semaphore with 3 slots, where 3 are available.
            Bouncer = new Semaphore(3, 3);

            // Open the nightclub.
            OpenNightclub();
        }

        public static void OpenNightclub()
        {
            for (int i = 1; i <= 50; i++)
            {
                // Let each guest enter on an own thread.
                Thread thread = new Thread(new ParameterizedThreadStart(Guest));
                thread.Start(i);
            }
        }

        public static void Guest(object args)
        {
            // Wait to enter the nightclub (a semaphore to be released).
            Console.WriteLine("Guest {0} is waiting to entering nightclub.", args);
            Bouncer.WaitOne();          

            // Do some dancing.
            Console.WriteLine("Guest {0} is doing some dancing.", args);
            Thread.Sleep(500);

            // Let one guest out (release one semaphore).
            Console.WriteLine("Guest {0} is leaving the nightclub.", args);
            Bouncer.Release(1);
        }
    }
}

互斥量基本上就是信号量(1,1)，并且经常在全局范围内使用(应用范围内使用，否则可以说锁更合适)。当从全局可访问的列表中删除节点时，可以使用全局互斥(在删除节点时，最不希望另一个线程做一些事情)。当你获得互斥锁时，如果不同的线程试图获得同一个互斥锁，它将被置于睡眠状态，直到获得互斥锁的同一线程释放它。

@deepe是创建全局互斥的一个很好的例子

class SingleGlobalInstance : IDisposable
{
    public bool hasHandle = false;
    Mutex mutex;

    private void InitMutex()
    {
        string appGuid = ((GuidAttribute)Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(GuidAttribute), false).GetValue(0)).Value.ToString();
        string mutexId = string.Format("Global\\{{{0}}}", appGuid);
        mutex = new Mutex(false, mutexId);

        var allowEveryoneRule = new MutexAccessRule(new SecurityIdentifier(WellKnownSidType.WorldSid, null), MutexRights.FullControl, AccessControlType.Allow);
        var securitySettings = new MutexSecurity();
        securitySettings.AddAccessRule(allowEveryoneRule);
        mutex.SetAccessControl(securitySettings);
    }

    public SingleGlobalInstance(int timeOut)
    {
        InitMutex();
        try
        {
            if(timeOut < 0)
                hasHandle = mutex.WaitOne(Timeout.Infinite, false);
            else
                hasHandle = mutex.WaitOne(timeOut, false);

            if (hasHandle == false)
                throw new TimeoutException("Timeout waiting for exclusive access on SingleInstance");
        }
        catch (AbandonedMutexException)
        {
            hasHandle = true;
        }
    }


    public void Dispose()
    {
        if (mutex != null)
        {
            if (hasHandle)
                mutex.ReleaseMutex();
            mutex.Dispose();
        }
    }
}

然后用like:

using (new SingleGlobalInstance(1000)) //1000ms timeout on global lock
{
    //Only 1 of these runs at a time
    GlobalNodeList.Remove(node)
}

希望这能为您节省一些时间。

使用Linux变体上的C编程作为示例的基本情况。

锁:

•通常是一个非常简单的构造二进制在操作中锁定或解锁

•没有线程所有权、优先级、顺序等概念。

•通常是旋转锁，线程不断检查锁的可用性。

•通常依赖于原子操作，例如Test-and-set, compare-and-swap, fetch-and-add等。

•通常需要硬件支持原子操作。

文件锁:

•通常用于协调多个进程对文件的访问。

多个进程可以持有读锁，但是当任何一个进程持有写锁时，不允许其他进程获得读或写锁。

•示例:flock, fcntl等。

互斥:

互斥锁函数调用通常在内核空间中工作，并导致系统调用。

•它使用了所有权的概念。只有当前持有互斥锁的线程才能解锁它。

互斥不是递归的(异常:PTHREAD_MUTEX_RECURSIVE)。

•通常用于与条件变量关联，并作为参数传递给例如pthread_cond_signal, pthread_cond_wait等。

•一些UNIX系统允许多个进程使用互斥锁，尽管这可能不是在所有系统上强制执行。

信号量:

•这是一个内核维护的整数，其值不允许低于零。

•可用于同步进程。

信号量的值可以设置为大于1的值，在这种情况下，该值通常表示可用资源的数量。

•值限制为1和0的信号量称为二进制信号量。

关于这些词有很多误解。

这是之前的一篇文章(https://stackoverflow.com/a/24582076/3163691)，非常适合这里:

1)临界区(Critical Section) =用户对象，用于允许在一个进程中执行多个活动线程中的一个活动线程。其他未被选中的线程(@获取该对象)将进入睡眠状态。

[没有进程间能力，非常基本的对象]。

2)互斥信号量(Mutex Semaphore，又名Mutex)=内核对象，用于允许在不同的进程中，只执行一个活动线程。其他未被选中的线程(@获取该对象)将进入睡眠状态。该对象支持线程所有权、线程终止通知、递归(同一个线程的多个“acquire”调用)和“优先级反转避免”。

[进程间能力，使用非常安全，一种'高级'同步对象]。

3)计数信号量(又名Semaphore)=内核对象，用于允许来自许多其他线程的一组活动线程的执行。其他未被选中的线程(@获取该对象)将进入睡眠状态。

[然而，进程间功能使用起来不太安全，因为它缺乏以下'互斥'属性:线程终止通知，递归?，“优先倒置规避”?等)。

4)现在，说到“自旋锁”，首先是一些定义:

关键区域(Critical Region):由两个或多个进程共享的内存区域。

Lock=其值允许或拒绝进入“关键区域”的变量。(它可以被实现为一个简单的“布尔标志”)。

忙碌等待=持续测试一个变量，直到某个值出现。

最后:

自旋锁(Spinlock)=一种使用忙等待的锁。(锁的获取是通过xchg或类似的原子操作完成的)。

没有线程睡眠，主要只在内核级使用。对于用户级别代码无效]。

作为最后的评论，我不确定，但我可以跟你打赌，上面的前3个同步对象(#1，#2和#3)使用这个简单的野兽(#4)作为它们实现的一部分。

祝你有愉快的一天!

引用:

-《嵌入式系统的实时概念》，作者:Qing Li和Caroline Yao (CMP Books)。

——安德鲁·塔南鲍姆(皮尔逊教育国际)的《现代操作系统》(第三期)。

-为微软Windows编程应用程序(第4)由Jeffrey Richter(微软编程系列)。

另外，你可以看看看看: https://stackoverflow.com/a/24586803/3163691

锁，互斥，信号量

这是一个普遍的愿景。细节取决于真正的语言实现

锁线程同步工具。当线程获得锁时，它就变成了一个能够执行代码块的单一线程。所有其他线程都被阻塞。只有拥有锁的线程才能解锁

互斥锁——互斥锁。这是一种锁。在某些语言中它是进程间机制，在某些语言中它是锁的同义词。例如，Java在synchronized和Java .util.concurrent.locks. lock中使用锁

信号量——允许多个线程访问共享资源。你可以发现互斥也可以通过信号量来实现。它是一个独立的对象，用于管理对共享资源的访问。您可以发现任何线程都可以发出信号并解除阻塞。它也被用于信号

[iOS锁，互斥量，信号量]