为什么说锁违反了抽象和可组合性原则？答案

【问题标题】：Why are locks said to violate the principles of abstraction and composability?为什么说锁违反了抽象和可组合性原则？
【发布时间】：2018-04-24 09:40:16
【问题描述】：

我在 Google 甚至 StackOverflow 上都找不到任何明确的答案来回答这个问题。

据我了解

使用锁的线程可能会破坏抽象
锁不可组合

但是锁如何以及为什么会破坏抽象和可组合性？

【问题讨论】：

据我了解...锁不会组合。可组合系统应提供可以按任何顺序选择和组装的组件，以满足特定要求。
希望对系统设计和线程并行有经验和/或了解的人可以为我解答这个问题。
也许这有帮助：我认为锁是单例，所以也许查找单例模式可以给你答案。
很遗憾，这并没有帮助我尝试理解锁是如何说违反抽象和可组合性原则的。

标签： abstraction locks system-design

【解决方案1】：

我不是专家，也无法在网上找到任何东西。我可能和你在大学做同样的事情，这就是我想出的（从个人经验来说）。

锁对抽象原则造成的问题是锁的状态及其资源可能无法由当前执行的指令集的状态来确定。例如，在 C++ 中，您可以有一个 Baker 类，它需要对某些 Oven 对象进行互斥访问。面包师需要经常使用烤箱（打开/关闭/放入东西）并且需要对烤箱的独占访问权限才能做到这一点，但这不能真正抽象出来，因为他何时需要这种互斥访问权限可能对他的功能很重要.

我们可能需要向我们的系统添加与面包师不同的功能，但需要对面包师正在使用的同一个烤箱进行互斥访问。在实现这些更改时，由于锁如何同时依赖于多个线程的状态，我们不能保证先前抽象的 Baker 类的行为在我们的程序运行时会保持不变。（例如：如果烤箱被另一个线程使用，面包师可能会决定等待 30 分钟，然后再检查烤箱是否空闲，这可能是不希望的、低效的行为）。

由于同样的问题，锁也违反了可组合性原则，因为如果程序的不同组件都依赖于彼此在多线程应用程序中潜在的未定义行为，则它们无法无缝组合。

希望对您有所帮助 - 让我知道您的想法，这样我们就可以一起取得成功。

【讨论】：

是的，我很确定我们都在做 CAB401：P 我今天刚刚和几个人讨论过这个问题，得出了同样的结论。抽象是一个非常有趣的讨论。谢谢芽。 :)

【解决方案2】：

非正式地，可组合性意味着将两个或多个函数式程序组合成一个更大的程序。组合应该基于已发布的接口，而不是了解内部细节。

请参阅https://en.wikipedia.org/wiki/Lock_(computer_science)#cite_note-5。在这个例子中，不知道锁定协议（账户类的实现细节）就无法正确编写转账方法

【讨论】：