银行情况出现僵局问题

Question

我有一个问题，我无法解决这个问题

void Transfer(Account a, Account b, decimal amount) 
{
       lock (a) {
             lock (b) {
                         if (a.Balance < amount)
                         throw new InsufficientFundsExc();
                         a.Balance -= amount;
                         b.Balance += amount;
                         }
                   }
}

，问题是“这是银行帐户之间的转账。”lock(...)”结构用于对抗竞争条件。这是什么问题？您提出什么解决方案？可以你帮我吗？

Answer 1

如果您在从 B 到 A 的转账的同时进行从 A 到 B 的转账，则可能会出现死锁，因为您没有锁定订单。

• 线程 1 锁定 A
• 线程 2 锁定 B
• 线程 1 等待 B
• 线程 2 等待 A
• 死亡

但是为什么这段代码首先是多线程的呢？

您需要始终按照相同的顺序取锁。例如，为每个锁提供一个整数 ID，并始终首先锁定较低的 ID。

Answer 2

如果您可以对帐户进行排序（通过 ID 号或其他方式），您始终可以先锁定 ID 较低的帐户。这将确保没有线程尝试在另一个线程先锁定 a 然后 b 的同时先锁定 a 然后 b >，因为它们都会首先锁定a。

Answer 3

死锁

Transfer(a,b,10.0) 时发生 ；和传输（b，a，10.0）；同时被调用
第一次调用将锁定
那么第二个可以在第一个锁定 a 之前锁定 b
都无法继续 ->僵局

Answer 4

正如 CodeInChaos 所暗示的那样，您的问题是潜在的死锁。如果您不明白什么是死锁，那么我建议您阅读维基百科上的哲学家就餐问题。

本文实际解释了该问题，并提出了一些解决方案，包括使用锁定顺序。

编辑：
为了进一步将您的问题与本文联系起来，银行帐户是分叉（即只能独占使用的共享资源，因此需要锁定），访问代码的线程是哲学家（即不时需要使用的实体）可锁定资源）。

Answer 5

@RatchetFreak 对于为什么会发生这种情况的回答一针见血。我认为您遇到的主要问题是锁是一个非常低级别的构造，这使得很难理智地考虑线程场景。

我建议（如果可能的话）使用一组稍高级别的构造来让自己的生活更轻松。 Daniel Chamber 在他的库中提供了一套很好的轻量级实用程序。

Answer 6

想象一下，两个非常固执的女士和她们的丈夫一起去度假屋。第二天早上他们醒来，发现那些人已经走了。剩下的唯一衣服：一条裙子和一件衬衫（似乎其中一个男人喜欢穿女装 - 可以解释很多）。女士们意识到需要去买东西——食物、衣服、新丈夫。她们都想“好吧，我穿上衣服就走”，一个穿上裙子，另一个穿上衬衫。他们看到了发生的事情，但每个人都太固执，无法改变他们的计划（而且太害羞，不敢半裸出去）。他们的固执就像一台愚蠢的计算机遵循着“当时看起来不错”的程序。他们不能/不会自动修改他们在遇到“运行时错误”时所采取的看似明智的方法，因此他们都注定要饿死。这是一个死锁：等待你无法获得的资源，因为有人在等待你自己占用的资源。

如果有更多的远见和计划，他们本可以找到一种策略来确保他们中的一个人逃脱。例如：

• 基于所寻找的对象的顺序：
  • 例如，只有当你已经拿到裙子时，你才能拿衬衫（至少有锁，保证争夺它的两条线之一可以拿到它，而不会把它撕成两半），或者
• 根据意愿订购-成为业主：
  • 如果两人同时出去，谁生日早谁先去，如果生日相同则谁高，依此类推，OR
• 都再次脱光并在短暂但随机的间隔后尝试

等等。