可以在 Linux 上实现正确的故障安全进程共享屏障吗？

Question

在过去的一个问题中，我询问了如何在没有破坏竞赛的情况下实现 pthread 屏障：

How can barriers be destroyable as soon as pthread_barrier_wait returns?

并从 Michael Burr 那里收到了针对流程本地障碍的完美解决方案，但对于流程共享障碍却失败了。后来我们也摸索了一些想法，但始终没有得出令人满意的结论，甚至没有开始涉足资源故障案例。

是否可以在 Linux 上制作满足这些条件的屏障：

• 进程共享（可以在任何共享内存中创建）。
• 在屏障等待函数返回后立即从任何线程取消映射或销毁屏障是安全的。
• 由于资源分配失败而无法失败。

Michael 解决进程共享案例的尝试（请参阅链接的问题）有一个不幸的属性，即必须在等待时分配某种系统资源，这意味着等待可能会失败。并且不清楚当屏障等待失败时调用者可以合理地做什么，因为屏障的全部意义在于在剩余的N-1 线程到达它之前继续进行是不安全的......

内核空间解决方案可能是唯一的方法，但即使这样也很困难，因为信​​号可能会中断等待而没有可靠的方法来恢复它...

Answer 1

这对于 Linux futex API 是不可能的，我认为这也可以得到证明。

我们这里基本上有这样一个场景，其中 N 个进程必须被一个最终进程可靠地唤醒，并且在最终唤醒之后，任何进程都不能接触任何共享内存（因为它可能被异步销毁或重用）。虽然我们可以很容易地唤醒所有进程，但基本的竞争条件是在唤醒和等待之间；如果我们在等待之前发出唤醒，那么落后者永远不会醒来。

通常的解决方案是让散乱者在等待的同时自动检查状态变量；如果唤醒已经发生，这允许它完全避免睡眠。但是，我们不能在这里这样做——一旦唤醒成为可能，触摸共享内存是不安全的！

另一种方法是实际检查是否所有进程都已进入睡眠状态。但是，这对于 Linux futex API 是不可能的。服务员数量的唯一指示是来自 FUTEX_WAKE 的返回值；如果它返回的服务员数量少于您预期的数量，您就知道有些人还没有睡着。然而，即使我们发现我们没有唤醒足够多的服务员，也为时已晚——确实唤醒的进程之一可能已经破坏了屏障！

因此，不幸的是，这种可立即销毁的原语无法使用 Linux futex API 构建。

请注意，在一个服务员，一个唤醒者的特定情况下，可能会解决该问题；如果 FUTEX_WAKE 返回零，我们知道实际上还没有人被唤醒，所以你有机会恢复。然而，把它变成一个高效的算法是相当棘手的。

向 futex 模型添加一个强大的扩展来解决这个问题是很棘手的。基本问题是，我们需要知道 N 个线程何时成功进入等待状态，并以原子方式将它们全部唤醒。但是，这些线程中的任何一个都可能随时等待运行信号处理程序 - 实际上，唤醒线程也可能等待信号处理程序。

然而，一种可行的方法是在 NT API 中扩展keyed event 模型。使用键控事件，线程成对地从锁中释放；如果您有一个没有“等待”的“释放”，则“释放”调用会阻止“等待”。

由于信号处理程序的问题，这本身是不够的；但是，如果我们允许“释放”调用来指定要以原子方式唤醒的线程数，则此方法有效。您只需让屏障中的每个线程减少一个计数，然后“等待”该地址上的键控事件。最后一个线程“释放”N - 1 个线程。在所有 N-1 个线程都进入这个键控事件状态之前，内核不允许处理任何唤醒事件；如果任何线程由于信号（包括释放线程）而离开 futex 调用，这将完全阻止任何唤醒，直到所有线程都返回。

Answer 2

在 SO chat 上与 bdonlan 进行了长时间的讨论后，我想我有一个解决方案。基本上，我们将问题分解为两个自同步释放问题：销毁操作和取消映射。

处理破坏很容易：只需让pthread_barrier_destroy 函数等待所有服务员停止检查屏障。这可以通过在屏障中设置使用计数，在进入/退出等待函数时原子地递增/递减，并让销毁函数旋转等待计数达到零来完成。 （也可以在这里使用 futex，而不仅仅是旋转，如果你在使用计数的高位或类似位置粘贴一个服务员标志。）

处理取消映射也很容易，但不是本地的：通过向系统调用包装器添加锁定，确保在屏障服务员退出过程中时不会发生带有MAP_FIXED 标志的munmap 或mmap。这需要一种特殊的读写锁。最后一个到达屏障的服务员应该在munmap rw-lock 上获取一个读锁，当最后一个服务员退出时（当递减用户计数导致计数为 0 时），该读锁将被释放。 munmap 和 mmap 可以通过使编写器锁定递归来实现可重入（正如某些程序可能期望的那样，即使 POSIX 不需要它）。实际上，读者和作者完全对称的一种锁，并且每种类型的锁都排除了相反类型的锁但不是相同类型的锁，应该效果最好。

Answer 3

好吧，我想我可以用笨拙的方法做到这一点......

让“障碍”成为它自己的进程在侦听套接字。将 barrier_wait 实现为：

open connection to barrier process
send message telling barrier process I am waiting
block in read() waiting for reply

一旦有 N 个线程在等待，屏障进程就会告诉所有线程继续。然后每个服务员关闭与屏障进程的连接并继续。

将 barrier_destroy 实现为：

open connection to barrier process
send message telling barrier process to go away
close connection

一旦所有连接都关闭并且屏障进程被告知离开，它就会退出。

[编辑：当然，这会分配和销毁套接字作为等待和释放操作的一部分。但我认为你可以不这样做就实现相同的协议；见下文。]

第一个问题：这个协议真的有效吗？我认为可以，但可能我不了解要求。

第二个问题：如果它确实有效，是否可以在没有额外流程开销的情况下进行模拟？

我相信答案是“是”。您可以让每个线程在适当的时候“扮演”屏障进程的角色。您只需要一个主互斥锁，由当前正在“扮演”屏障进程的任何线程持有。细节，细节......好的，所以 barrier_wait 可能看起来像：

lock(master_mutex);
++waiter_count;
if (waiter_count < N)
    cond_wait(master_condition_variable, master_mutex);
else
    cond_broadcast(master_condition_variable);
--waiter_count;
bool do_release = time_to_die && waiter_count == 0;
unlock(master_mutex);
if (do_release)
    release_resources();

这里master_mutex（互斥体）、master_condition_variable（条件变量）、waiter_count（无符号整数）、N（另一个无符号整数）和time_to_die（布尔值）都是共享的由 barrier_init 分配和初始化的状态。 waiter_count 初始化为零，time_to_die 初始化为 false，N 初始化为屏障正在等待的线程数。

那么屏障破坏将是：

lock(master_mutex);
time_to_die = true;
bool do_release = waiter_count == 0;
unlock(master_mutex);
if (do_release)
    release_resources();

不确定有关信号处理等的所有细节......但我认为“最后一个关灯”的基本想法是可行的。