使用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的信号量称为二进制信号量。

大多数问题都可以用(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.

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

使用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的信号量称为二进制信号量。

锁只允许一个线程进入被锁的部分，并且锁不与任何其他进程共享。

互斥锁与锁相同，但它可以是系统范围的(由多个进程共享)。

信号量的作用与互斥量相同，但允许x个线程进入，这可以用于限制同时运行的cpu、io或ram密集型任务的数量。

关于互斥量和信号量区别的更详细的文章请阅读这里。

您还可以使用读/写锁，在任何给定时间允许无限数量的读取器或1个写入器。

这些描述是从。net的角度出发的，对于所有操作系统/语言可能不是100%准确。

维基百科有一个关于信号量和互斥量区别的很好的章节:

A mutex is essentially the same thing as a binary semaphore and sometimes uses the same basic implementation. The differences between them are: Mutexes have a concept of an owner, which is the process that locked the mutex. Only the process that locked the mutex can unlock it. In contrast, a semaphore has no concept of an owner. Any process can unlock a semaphore. Unlike semaphores, mutexes provide priority inversion safety. Since the mutex knows its current owner, it is possible to promote the priority of the owner whenever a higher-priority task starts waiting on the mutex. Mutexes also provide deletion safety, where the process holding the mutex cannot be accidentally deleted. Semaphores do not provide this.

我的理解是互斥量只能在单个进程中使用，但可以跨多个线程使用，而信号量可以跨多个进程和它们对应的线程集使用。

此外，互斥是二进制的(它要么被锁定要么被解锁)，而信号量有计数的概念，或者一个包含多个锁定和解锁请求的队列。

有人能证实我的解释吗?我说的是Linux环境，特别是使用内核2.6.32的Red Hat Enterprise Linux (RHEL)版本6。