在过去的一个问题中，我询问了如何在没有破坏竞赛的情况下实施pthread障碍：
How can barriers be destroyable as soon as pthread_barrier_wait returns?
并且从迈克尔·伯尔那里获得了一个完美的流程局部障碍解决方案，但却没有遇到流程共享的障碍。我们后来研究了一些想法，但从未得出令人满意的结论，甚至没有开始陷入资源失败的情况。在Linux上是否有可能形成满足这些条件的障碍：
N-1线程到达它之前继续进行是不安全的......
内核空间解决方案可能是唯一的方法，但即使这很困难，因为信号可能会中断等待而没有可靠的方法来恢复它......
答案 0 :(得分：2)
使用Linux futex API是不可能的，我认为这也可以证明。
我们这里基本上有一个场景，其中N个进程必须被一个最终进程可靠地唤醒，并且在最终唤醒之后没有任何进程可以触及任何共享内存（因为它可能被异步破坏或重用）。虽然我们可以轻松地唤醒所有过程，但基本竞争条件是在唤醒和等待之间;如果我们在等待之前发出唤醒，那么落后者永远不会醒来。
通常的解决办法就是让straggler用等待原子检查一个状态变量;如果唤醒已经发生，这可以让它完全避免睡觉。但是，我们不能在这里做到这一点 - 只要唤醒成为可能，触摸共享内存就不安全了！
另一种方法是实际检查所有进程是否已进入休眠状态。但是，Linux futex API无法实现这一点;服务员数量的唯一指示是来自FUTEX_WAKE的返回值;如果它的回报率低于你预期的服务员数量，你知道有些人还没睡着。然而，即使我们发现我们没有唤醒足够的服务员，也不能做任何事情 - 做出唤醒的过程之一可能已经破坏了障碍！
因此，遗憾的是，无法使用Linux futex API构建这种可立即销毁的原语。
请注意，在一个服务员，一个工作人员的特定情况下，可以解决问题;如果FUTEX_WAKE返回零，我们知道还没有人被唤醒，所以你有机会恢复。然而，将其变成一种有效的算法非常棘手。
为futex模型添加一个强大的扩展来解决这个问题是很棘手的。基本问题是，我们需要知道N个线程何时成功进入等待状态，并以原子方式唤醒它们。但是，任何这些线程都可能在任何时候都等待运行信号处理程序 - 事实上，waker线程也可能会等待信号处理程序。
然而，一种可行的方法是NT API中keyed event模型的扩展。对于键控事件，线程从锁中成对释放;如果你有'释放'没有'等待'，'释放'呼叫阻止'等待'。
由于信号处理程序的问题，这本身是不够的;但是，如果我们允许'release'调用指定要原子唤醒的多个线程，这是有效的。您只需让屏障中的每个线程递减一个计数，然后对该地址上的键控事件“等待”。最后一个线程'释放'N - 1个线程。在所有N-1个线程都进入此键控事件状态之前，内核不允许处理任何唤醒事件。如果任何线程由于信号（包括释放线程）而离开futex调用，这将阻止任何唤醒，直到所有线程都返回。
答案 1 :(得分：1)
经过与bdonlan在SO聊天上的长时间讨论后，我想我有一个解决方案。基本上，我们将问题分解为两个自我同步的释放问题：销毁操作和取消映射。
处理破坏很容易：只需让pthread_barrier_destroy功能等待所有服务员停止检查屏障。这可以通过在屏障中使用计数，在进入/退出到等待函数时原子递增/递减，并使销毁函数旋转等待计数达到零来完成。 （也可以在这里使用futex，而不是仅仅旋转，如果你在使用计数的高位或类似位置粘贴服务员标志。）
处理取消映射也很容易，但非本地：通过添加锁定，确保在屏障服务器处于退出过程中时，munmap或mmap MAP_FIXED标记不会出现到syscall包装器。这需要一种专门的读写器锁。到达屏障的最后一个服务员应该抓住munmap rw-lock上的读锁定，当最终服务员退出时（当递减用户计数导致计数为0时）将释放该锁定。 munmap和mmap可以通过使写入程序锁递归而变为可重入（因为某些程序可能期望，即使POSIX不需要它）。实际上，读者和作者完全对称的一种锁，每种类型的锁都排除了相反类型的锁，但不是同一类型，应该效果最好。
答案 2 :(得分：0)
嗯，我想我可以用笨拙的方法做到这一点......
将“屏障”作为自己的进程侦听套接字。将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（另一个无符号整数）和{{ 1}}（布尔值）都是由barrier_init分配和初始化的共享状态。 time_to_die初始化为零，waiter_count为false，time_to_die为屏障等待的线程数。
然后barrier_destroy将是：
N不确定有关信号处理的所有细节等......但我认为“最后一次关灯”的基本思路是可行的。