Mutex可能对系统性能有什么副作用？

Question

拥有共享资源的多线程应用程序需要使用互斥锁对其访问进行序列化。

如果我想下列条件的应用程序满足：

1 - 无互斥误操作导致死锁，长时间等待或其他灾难性的后果。

2 - 共享资源具有处理所有互斥锁问题的访问器方法（因为等待互斥量最大限度地释放而导致延迟的尝试）。

接受互斥锁是解决与共享资源保护相关的许多问题的问题解决者。使用互斥体对性能有任何副作用？如果是的话应该是什么选择（可能是其他同步机制）？

为了更清楚我的意思，我会考虑下面的例子：

线程读取多个线程之间共享的全局变量的尝试。如果我可以考虑：

a - 阅读操作需要（X us）。

b - 互斥量使用会增加（Y us）的开销。

Ç - 读操作不得超过ž我们其中Z> = X，但ž< X + Y

其次，我认为我可以假设互斥确保互斥，但在的负面影响为代价的表现（这可能是轻微的或相当大的影响取决于上下文）。

互斥锁在很多情况下都很有用，但是在任何情况下都应该避免（或替换）它们，因为它们对系统性能有负面影响，尽管它们在使用时非常谨慎？

注意：这里我指的是作为内核服务提供的Mutexes。我不是指任何试图模仿Mutex（内核服务）的应用程序实现。

Answer 1

如果你担心通过获得一个免费的互斥量并释放它而增加的额外开销，那么你不应该担心这一点。是的，获取和释放互斥锁所需的代码会向使用该资源的线程添加非零数量的开销。但根据我的经验，开销的数量可以忽略不计，我不记得曾经担心它或解决它。如果你需要一个互斥体来保护共享资源，那么你应该使用一个互斥体。

如果您担心一个线程可能会使资源过长，从而阻止另一个线程及时访问资源，那么这是一个值得关注的问题，这正是您对系统设计的关注所在。一些用于寻址的设计技术这个问题包括：最小化互斥锁被占用的时间，线程优先级和优先级继承。

在某些情况下，您可以通过限制对单个线程的资源访问来避免使用互斥锁。换句话说，不要在线程之间共享资源。其他希望使用资源的线程必须与资源的线程进行通信。例如，您可以有一个负责串行端口传输的线程。任何其他需要发送串行消息的线程都会向串行线程的邮箱或队列发送请求。串行线程简单地挂在邮箱/队列上，然后发送所有收到的请求。这样就不需要互斥体，因为串行线程是直接使用资源的唯一线程。请注意，由于多个请求可能会堆积在邮箱/队列中，导致某些消息传输延迟，因此该技术仍需要一些系统设计维护。