问题标签 [livelock]

假设您有一段由多个线程运行的代码。现在进一步假设这些线程中的每一个都想要锁定同一组互斥锁，比如 5，但不是按特定顺序：

线程 1：mutex1、mutex2、mutex3、mutex4、mutex5

线程 1：mutex3、mutex2、mutex4、mutex4、mutex1

现在，如果您要实现一个采用这 5 个互斥锁并尝试锁定它们的函数，您将如何避免死锁和活锁？

由于应避免死锁，因此锁定语句的简单列表是毫无疑问的。现在我想到的是（伪代码）：

这种方法的问题是它肯定会导致活锁并消耗大量的cpu功率。

所以我想出的唯一解决方案是为每个线程配备一个优先级编号，并使用该编号在循环开始时指定（增加）睡眠时间：

您如何看待这个解决方案？这是一个合适的方法吗？我有哪些选择？科学界有没有关于这个问题的文献？

我正在准备 Java SE 7 程序员 II 考试。在其中一个模拟考试中，有一个练习可以从代码遭受的线程问题中找出答案。这是代码：

他们说这是活锁。我看不到。请有人可以更详细地解释一下。

进程 A 和 B 都在 Redis 资源 R 上运行。

这些进程可以并行执行，我需要这两个进程在它们更改 R 时确定 R 的值。

因此，我将Redis 事务与WATCH 命令一起使用。来自文档：“我们要求 Redis 仅在没有其他客户端修改任何 WATCHed 键时才执行事务。否则根本不输入事务。”

要在失败的情况下重试，建议的方法是循环 Watch/Multi-exec 循环，直到它成功。但是，我担心 A 和 B 都可能开始无限循环（即：活锁）。

这有什么好担心的？更好的是，该怎么办？在重试时设置随机超时会解决问题吗？

当我偶然发现一些我不理解的行为时，我试图使用 Java 同步“原语”（synchronized、wait()、notify() ）来实现类似于 Java 的有界BlockingQueue接口的东西。

我创建了一个能够存储 1 个元素的队列，创建了两个等待从队列中获取值的线程，启动它们，然后尝试将两个值放入主线程的同步块中的队列中。大多数情况下它可以工作，但有时等待一个值的两个线程似乎开始互相唤醒并且不让主线程进入同步块。

这是我的（简化的）代码：

这是我在“阻塞”时看到的内容：

但是，如果我将 addWhenHasSpace 和 getWhenNotEmpty 方法的 while(...) 循环内的 notify() 调用更改为 notifyAll()，它“总是”通过。

我的问题是：为什么在这种情况下 notify() 和 notifyAll() 方法的行为会有所不同，以及 notify() 的行为为什么会这样？

在这种情况下，我希望这两种方法的行为方式相同（两个线程等待，一个阻塞），因为：

1. 在我看来，在这种情况下 notifyAll() 只会唤醒另一个线程，与 notify() 相同；
2. 看起来唤醒线程的方法的选择会影响被唤醒的线程（我猜想变成 RUNNABLE）和主线程（已经被 BLOCKED）后来竞争锁的方式——这不是我所期望的javadoc 以及在互联网上搜索该主题。

或者也许我完全做错了什么？

我正在开发一个带有两个线程的循环缓冲区：消费者和生产者。我正在使用主动等待Thread.yield。我知道可以使用信号量来做到这一点，但我想要没有信号量的缓冲区。

两者都有一个共享变量：bufferCircular.

当缓冲区没有充满有用信息时，producer在数组位置写入数据p，当有一些有用信息consumer时，在数组位置读取数据c。变量nElemfromBufferCircular是尚未读取的值数据的数量。

该程序运行良好 9/10 次。然后，有时，它会在屏幕上显示最后一个元素（循环的编号 500）之前陷入无限循环，或者只是不显示任何元素。

我想可能是一个liveLock，但我找不到错误。

共享变量：

生产者线程：

消费者线程：

主要：

欢迎任何帮助。

当用于计算的函数在同一个映射上调用 #computeIfAbsent 时，我在并发哈希映射 #computeIfAbsent 中达到了实时锁定条件。

概念上调用调用如下所示

（计算之间消耗了大约 3ms 的 cpu）。不幸的是，我无法提出好的单元测试来一致地重现问题。

然而

如果计算函数试图删除调用它的键，还有另一个活锁可能会提供一些线索：

虽然第二个示例是并发哈希映射的使用相当复杂，但它会产生与第一个活锁相同的堆栈跟踪，因此可能会有所帮助。

任何帮助将不胜感激！

我是 Java 新手，正在尝试学习活锁的概念。

我在网上找到了一个活锁的好例子，一对夫妻试图喝汤，但他们之间只有一个勺子。夫妻双方都太客气了，对方还没吃饭就递勺子。

我的问题是，我们应该怎么做才能克服一般的活锁问题，在这个特定的例子中？我正在寻找修改我的代码以演示问题的解决方案。

i'm trying to do a simple program with Dekker's Algorithm but with 3 processes. Here's my code:

I don't know if my code is 100% correct. If P wants to enter in the CS, first, he has to check if Q or R wants to enter too, if it isn't his turn, he waits. Same procedure with Thread Q and R.

• With 2000000 iterations: the program doesn't work
• With 200 iterations: the program works sometimes

I guess Dekker's Algorithm doesn't work for 3 processes but i need to know if my code is correct and why my program fail.

Thanks.

我在使用 Objective-C 中的块时遇到问题。我的问题是，函数 readDataFromCharactUUID 的完成块永远不会使用 do-while-loop 调用。在不使用 do-while-loop 的情况下，它会被调用一次。

我想用我的代码做的是经常从 BLE 特征中读取一个值，因为值是 0x01。

我的问题：为什么从不执行完成块？我能做什么，完成块在我的情况下被执行？

使用代码：

先感谢您！

调度方案：抢占式优先调度

情况 ：

进程 L（低优先级）获取资源（R）上的自旋锁。当仍处于临界区时，由于另一个进程 - H（更高优先级）进入就绪队列，L 被抢占。.

然而，H 还需要访问资源 R 并因此尝试获取自旋锁，这导致 H 忙于等待。因为使用了自旋锁，所以 H 永远不会真正进入 Wait 并且将始终处于 Running 状态或 Ready 状态（以防更高优先级的进程到达就绪队列），从而阻止 L 或任何优先级低于 H 的进程执行。

A) 所有优先级小于 H 的进程都可以认为处于饥饿状态

B) 所有优先级小于 H 的进程以及进程 H 都可以认为处于死锁状态。[但是，那么进程是否必须处于等待状态才能使系统被认为处于死锁状态？]

C）所有优先级小于H的进程以及进程H，都可以认为是处于活锁状态。[但是，只有H的状态不断变化，所有低优先级的进程都保持在Ready状态。如果系统处于活锁状态，所有进程的状态是否都需要不断更改（作为自旋锁的一部分）？]

D) H 单独可以被认为处于活锁状态，所有低优先级的进程都处于饥饿状态，而不是处于活锁状态。

E) H 不会进步，但不能被认为处于活锁状态。所有较低优先级的进程都处于饥饿状态，而不是处于活锁状态。

以上哪些说法是正确的？你可以解释吗？