什么是mutex - Linux快速入门教程

1. 概述 

当我们开始使用并行或并发编程时，通常我们遇到的第一件事是当两个并发（或并行）执行尝试访问同一资源（例如变量）时出现问题。互斥体是解决此问题的最简单解决方案之一。在下面的教程中，我们将解释它是如何工作的以及如何使用它。

2. 互斥体解释

互斥体究竟是什么？让我们想象一下早上与五名开发人员和Scrum Master的Scrum每日会议。其中一个正在沉迷于咖啡的美味中，在没有回过神来之前他无法说话。另一个人希望回到自己的办公桌前，完成当天SQL查询编写任务，而不是参加会议。其余的人（所有三个人）都了解会议的目标，并很高兴谈论他们所做的事情，因此他们开始同时发言。

这最终导致混乱，没有人明白任何事情。Scrum Master走上前，给其中一个开发人员一个球，并说：“只有有球的人才能说话！从那时起，他们相互理解，可以迅速结束会议：

 

 

 

如果我们考虑一下，SM通过定义系统中的关键部分解决了这种情况。我们理解“关键”这个词，开发人员（演员）将球用作向其他可以说话并且必须等待的人发出信号的工具。换句话说，球相互排除了开发人员的发言权。这种命名是如此普遍，以至于人们开始缩写：Mutex（MutualExclusion）。

3. 我们在哪里使用？

该概念可以应用于许多不同的情况，主要目标始终是能够定义关键部分：

• 具有写入和读取访问权限访问共享内存的多个线程
• 访问公共资源（打印机和相机）的多个进程

互斥体的一个常见实现是锁，可以获取（进入关键部分）和释放（离开关键部分）：

 

 

4. 属性

如上所述，关键部分保证一次只允许其中一个参与者访问。如果我们的系统设计得不好，我们最终可能会得到一个大的关键部分，其中只有一个参与者可以工作，而所有其他参与者总是必须等待互斥体得到解决。

这与顺序执行没有什么不同，所以我们没有通过选择并发编程来获得任何性能（如果你考虑一下，我们的Scrum示例就是这样）。这表明了关键部分定义的重要性。当我们设计我们的系统时，我们必须识别和本地化公共资源，以便能够从并行执行中受益。

另一个常见问题是死锁。为了好玩起见，让我们假设Scrum团队决定开发人员只有在完全完成的情况下才能传球，但他需要同事提供一些信息。会发生什么？

• 有球的人（“Dev A”）从“Dev B”中提出问题并等待答案
• “Dev B”（无球）知道答案，但他等待球能够说话
• “Dev A”在完全完成之前无法传球，他需要答案

 

这种情况有解决办法吗？不幸的是没有。我们的系统永远挂起，或者换句话说，处于死锁状态。

死锁可能发生，尤其是在具有多个锁的系统中。为了确保您的设计没有死锁，您应该在每个角色中以相同的顺序获取锁。

类似的现象也表现在第22条军规中。

5. 结论

在本文中，我们总结了互斥体的定义和属性，并了解了使用它们时可能遇到的问题。需要注意的是，有一些设计模式试图以不同于互斥体的方式解决参与者之间的交互。了解问题对于能够为其设计最佳解决方案至关重要。