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

Posted 2023-03-17

【中文标题】可以在 Linux 上实现正确的故障安全进程共享屏障吗？

【英文标题】：Can a correct fail-safe process-shared barrier be implemented on Linux?

【发布时间】：2011-10-19 15:07:10

【问题描述】：

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

How can barriers be destroyable as soon as pthread_barrier_wait returns?

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

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

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

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

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

【问题讨论】：

我不确定我是否真的理解您的问题，据我所知，NPTL 实现是故障安全的。屏障本身是在外部分配的，它的pthread_barrier_destroy 函数只与最后一个等待者同步。到底是什么问题？

@Hasturkun：参见 glibc 错误 #13065：sourceware.org/bugzilla/show_bug.cgi?id=13065

虽然缺少附件，但似乎描述了在屏障被破坏之前未映射内存的情况。如果我理解正确，那么在销毁屏障之前取消映射屏障永远是不安全的（除非您可以保证没有线程使用屏障，假设您不是最后一个用户）。 NPTL 实现永远不会在没有锁的情况下访问任何东西，pthread_barrier_destroy 需要锁，确保在销毁成功时没有人访问屏障内部（如果任何线程正在等待，它就不会这样做）。

只要保留其他可销毁的映射（例如在其他进程中），在屏障被销毁之前取消映射是安全的。这将是进程共享同步对象的标准用法，其中一个进程只需要在固定时间内访问它。

如果您可以保证您的进程没有使用它，那将是安全的，在这种情况下，确实不应该有问题。如果您决定在相关函数返回之前释放屏障（或任何其他原语）的底层内存，我认为没有任何理由期待任何类型的行为。您应该在取消映射内存之前同步所有用户，无论是显式地还是通过正确使用pthread_barrier_destroy。在后一种情况下，您可以稍后重新初始化屏障以供重用。

【参考方案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 调用，这将完全阻止任何唤醒，直到所有线程都返回。

【讨论】：

这里有一个想法：可以使用FUTEX_REQUEUE 操作（具有相同的源和目标地址以及 0 个唤醒）来查询一个 futex 有多少个服务员（它返回唤醒的数量和号码重新排队）。它还可以（可能）用于将服务员重新排队到甚至在服务员地址空间中不可见的 futex 上。也许这些操作足以实现诸如键控事件之类的东西？我认为唯一的大问题是当服务员被信号打断时会发生什么。即使您屏蔽了所有信号（不太合法...），仍然有SIGSTOP...

查询服务员的数量本质上是活泼的——该值可能会在系统调用返回的瞬间改变，因此除了性能优化之外，它没有任何用处。即使您开始将服务员一次一个地移动到唤醒器一侧的堆栈本地 futex 变量，服务员也可能被信号唤醒，然后返回到他们原来的等待状态。不，我认为这确实需要一个新的内核端操作。

如果被信号中断，您确定他们会重新开始等待原始队列吗？可能是吧;我得检查一下。我更希望 futex 等待系统调用失败并返回 EAGAIN，或者如果在重新排队后中断，则返回 0（唤醒），类似于 read 或 write 如果在读/写某些数据后中断，将返回部分传输。当然要确定我真的应该测试它......

我的另一个想法是pthread_barrier_init 操作用于进程共享屏障以创建一个新进程，该进程将成为永久屏障管理器，并通过 futex 进行通信。最终的唤醒可以通过在管理器进程的控制下查询一些文件系统对象来控制——可以在不需要分配资源的情况下查询一些东西，例如access。当然，由于似乎没有办法阻止等待此类事件，因此最好使用 futex ops（上述想法）优化等待，并且只使用 fs 进行“最终检查”。

@R..，是的，它会失败并返回 EAGAIN。此时，屏障代码必须返回等待原始队列。毕竟，它还会在哪里等待呢？然后考虑比赛，就像唤醒者在私有队列上发出 FUTEX_WAKE 并从屏障函数返回一样，睡眠者被信号唤醒并返回等待原始队列 - 即使它不再安全访问那段记忆。

【参考方案2】：

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

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

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

【讨论】：

后人聊天链接：chat.***.com/rooms/3811/…

我已经实现了我们讨论过的设计，它似乎正在工作。它通过了我的取消映射/破坏竞赛条件的基本测试，以及 NPTL 屏障测试，但我还没有对其进行过重的压力测试。由于所有服务员实际上都必须等待两次（第二次他们都在障碍物处，所以他们都可以在退出之前获取munmap 锁），因此性能会受到影响，但我仍在使用旧设计（由 Michael 提供） Burr) 用于非共享障碍。

【参考方案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();

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

【讨论】：

“打开连接”是一种操作，可能由于进程中或系统上全局打开的 fd 过多而失败。 :-( 我有一个更轻松（不需要额外的过程）的方法来做一个屏障，只是让第一个服务员创建一个先进先出，随后的服务员阻止尝试打开它，但这仍然取决于成功创建先进先出的能力。我假设一个人可以进入一个无限循环等待它成功......

我的答案的后半部分没有分配任何资源，除了在初始化期间......它有效吗？

您的方法可以防止在从障碍返回和破坏障碍之间进行竞赛的情况，但我认为调用者 取消映射 障碍完全没有帮助不破坏它。这当然是进程共享屏障的典型用法，您可能希望将其留给其他进程使用。

@R..：为什么调用者会在不先破坏屏障的情况下取消映射屏障？

因为有很多进程使用了​​屏障。它可能属于你已经完成通信的服务器进程，但它仍然需要屏障以便以后与其他进程通信。