multithreading - 轻量级互斥

Question

引用来自http://preshing.com/20111124/always-use-a-lightweight-mutex/

The Windows Critical Section is what we call a lightweight mutex. It’s optimized for the case when there are no other threads competing for the lock. To demonstrate using a simple example, here’s a single thread which locks and unlocks a Windows Mutex exactly one million times

这是否意味着轻量级互斥体只是智能的重(内核)互斥体？
“智能”是指 仅当互斥锁是免费的时才进行系统调用吗？

Answer 1

总而言之，是的:Windows上的上，关键部分和互斥体是相似的，但是关键部分的重量较轻，因为它们在没有争用时避免了系统调用。

Windows具有两种不同的互斥原语:关键部分和互斥体。它们具有相似的功能，但关键部分的速度比互斥体快得多。

互斥锁总是导致对内核的系统调用，这需要处理器环形模式切换，并且会产生大量开销。 (用户模式线程引发异常，然后该异常被运行在环0中的内核线程捕获；用户模式线程将保持暂停状态，直到执行返回内核模式为止。)尽管它们速度较慢，但​​互斥锁却更强大。灵活它们可以在进程之间共享，等待线程可以指定超时期限，等待线程还可以确定拥有互斥锁的线程是否终止或是否删除了互斥锁。

关键部分是重量较轻的对象，因此比互斥对象要快得多。在最常见的无竞争获取的情况下，关键部分的速度非常快，因为它们只是在用户模式下原子地递增一个值并立即返回。 (在内部， InterlockedCompareExchange API用于“获取”关键部分。)

只有在采集方面存在争用时，关键部分才切换到内核模式。在这种情况下，关键部分实际上在内部分配了一个信号量，将其存储在关键部分结构的专用字段中(该字段原本是未分配的)。因此，基本上，在争用的情况下，您会看到性能下降到互斥锁，因为您实际上正在使用互斥锁。用户模式线程被挂起，进入内核模式以等待信号量或事件。

Windows中的关键部分在某种程度上类似于Linux中的“futexes”。 futex是“ F ast U ser-space mu TEX ”，它像关键部分一样，仅在需要仲裁时才切换到内核模式。

关键部分的性能优势会带来严重的警告，包括无法指定等待超时时间，线程无法确定拥有线程在释放关键部分之前是否已终止，无法确定是否关键部分已删除，并且无法跨流程使用关键部分(关键部分是本地流程对象)。

因此，在决定关键部分和互斥对象之间时，应牢记以下准则:

如果要使用关键部分，则该操作必须是非阻塞的。如果某个操作可以阻塞(例如套接字)，则不应使用关键部分，因为它不允许等待线程指定等待超时，这可能导致死锁。

如果线程可能引发异常或意外终止，请使用互斥锁。对于关键部分，无法等待通知线程原始线程已终止或关键部分已删除。

当 protected 操作持续时间相对较短时，关键部分才最有意义。在这些情况下，最重要的是避免互斥量的开销，并且最不可能遇到关键部分问题的情况。

您会在网上找到许多基准测试，其中显示了关键部分和互斥对象之间的相对性能差异，包括 the article you link，它表示关键部分的速度比互斥对象快25倍。我在类(class)库中的一段评论很久以前读到的一篇文章说:“在奔腾II 300 MHz上，关键部分的往返(假设没有争用，因此不需要上下文切换)需要0.29。 µs。使用互斥锁需要5.3 µs。”当您可以避免内核模式转换时，共识似乎快了15–30％。我自己也没有为它做基准测试。 :-)

进一步阅读:

MSDN上的

Critical Section Objects:

A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used only by the threads of a single process. Event, mutex, and semaphore objects can also be used in a single-process application, but critical section objects provide a slightly faster, more efficient mechanism for mutual-exclusion synchronization (a processor-specific test and set instruction). Like a mutex object, a critical section object can be owned by only one thread at a time, which makes it useful for protecting a shared resource from simultaneous access. Unlike a mutex object, there is no way to tell whether a critical section has been abandoned.
[ … ]
A thread uses the EnterCriticalSection or TryEnterCriticalSection function to request ownership of a critical section. It uses the LeaveCriticalSection function to release ownership of a critical section. If the critical section object is currently owned by another thread, EnterCriticalSection waits indefinitely for ownership. In contrast, when a mutex object is used for mutual exclusion, the wait functions accept a specified time-out interval.

INFO: Critical Sections Versus Mutexes，也在MSDN上:

Critical sections and mutexes provide synchronization that is very similar, except that critical sections can be used only by the threads of a single process. There are two areas to consider when choosing which method to use within a single process:

1. Speed. The Synchronization overview says the following about critical sections:

   ... critical section objects provide a slightly faster, more efficient mechanism for mutual-exclusion synchronization. Critical sections use a processor-specific test and set instruction to determine mutual exclusion.

2. 死锁。同步概述对互斥量说以下内容:
   
   

   If a thread terminates without releasing its ownership of a mutex object, the mutex is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex, but the wait function's return value indicates that the mutex is abandoned.

   
   
   WaitForSingleObject()将为已被放弃的互斥量返回WAIT_ABANDONED。但是，互斥对象正在保护的资源处于未知状态。
   
   无法判断关键部分是否已被放弃。


The article you link to in the question也链接到 this post on Larry Osterman's blog，它提供了有关实现的一些更有趣的细节。