在之前的一个问题中，我问了如何在没有销毁竞争的情况下实现pthread屏障：
如何让屏障在pthread_barrier_wait返回后立即可销毁?
我从Michael Burr那里得到了对于进程本地屏障的完美解决方案，但该方案对于进程共享的屏障会失败。我们后来一起探讨了一些想法，但从未达成令人满意的结论，也没有开始研究资源故障的情况。
在Linux上是否可能创建一个符合以下条件的屏障：
Michael尝试解决进程共享的情况（请参见链接的问题），但具有不幸的性质，即在等待时间必须分配某种系统资源，这意味着等待可能会失败。当屏障等待失败时，调用者应该做什么是不清楚的，因为屏障的整个作用在于，在剩余的N-1线程到达之前，不安全继续执行操作。
可能只有内核空间的解决方案，但由于存在信号中断等情况，即使是这样也很困难，且没有可靠的方法来恢复它...
我们在这里实际上有一个场景，其中N个进程必须由一个最终进程可靠地唤醒，并且在最终唤醒之后，没有任何进程可以触摸任何共享内存（因为它可能会被异步销毁或重用）。虽然我们可以很容易地唤醒所有进程，但根本的竞争条件在于唤醒和等待之间；如果我们在等待之前发出唤醒，则落伍者永远不会醒来。
像这样的问题通常的解决方案是让落伍者在等待时原子地检查状态变量；如果唤醒已经发生，它可以完全避免睡眠。然而，在这里我们无法这样做——一旦唤醒变得可能，触摸共享内存就不安全了！
另一种方法是实际检查所有进程是否已经进入睡眠状态。然而，这在Linux futex API中是不可能的；等待者数量的唯一指示是FUTEX_WAKE的返回值；如果它返回少于您预期的等待者数量，则知道一些人还没有入睡。但是，即使我们发现我们没有唤醒足够的等待者，也为时已晚——已经醒来的进程中可能已经有一个销毁了屏障！
很遗憾，使用Linux futex API无法构建此类可立即销毁的原始对象。
FUTEX_REQUEUE 操作可以用于查询一个 futex 有多少个等待者（它返回唤醒的数量和重新排队的数量之和），使用时源地址和目标地址相同，唤醒数为0。它也可以（大概）用于将等待者重新排队到在等待者地址空间中甚至看不到的 futex 上。也许这些操作足以实现类似键控事件的东西？我认为唯一的大问题是当等待者被信号中断时会发生什么。即使你阻塞了所有信号（不太合法...），仍然有 SIGSTOP... - R.. GitHub STOP HELPING ICEEAGAIN或返回0（唤醒），类似于read或write在读/写一些数据后被中断时返回部分传输。当然，要确保我应该真正测试一下... - R.. GitHub STOP HELPING ICEpthread_barrier_init操作，为了创建一个进程共享的屏障，可以创建一个新进程作为永久的屏障管理器，并通过futex进行通信。最终的唤醒可以通过查询一些文件系统对象来控制，这些对象在管理进程的控制下，可以在不必分配资源的情况下进行查询，例如access。当然，由于似乎没有办法阻塞等待这样的事件，因此希望通过futex操作（上述想法）来优化等待，并仅在“最终检查”时使用fs。 - R.. GitHub STOP HELPING ICEpthread_barrier_destroy函数等待所有等待者停止检查屏障即可。这可以通过在屏障中具有使用计数来完成，该计数在进入/退出等待函数时原子地递增/递减，并且使销毁函数旋转等待计数达到零。（如果将等待器标志放置在使用计数或类似计数的高位中，则还可以在此处使用futex，而不仅仅是旋转。）
处理取消映射也很容易，但是非本地：通过向系统调用包装器添加锁定，确保在屏障等待者正在退出的过程中不能发生带有MAP_FIXED标志的munmap或mmap，这需要一种专门的读写锁。到达屏障的最后一个等待者应该在munmap读写锁上获取读锁，在最终等待者退出时（当减少用户计数结果为0时）将释放该锁。通过使写入锁递归，可以使munmap和mmap可重入（正如某些程序可能期望的那样，尽管POSIX不要求）。实际上，一种读者和写者完全对称的锁，每种类型的锁都排除相反类型的锁而不是同一类型的锁，应该效果最好。
munmap锁），但是对于非pshared屏障，我仍然使用旧的设计（由Michael Burr提供）。 - R.. GitHub STOP HELPING ICE嗯，我觉得我可以用笨拙的方法做到这一点...
让“屏障”成为自己监听套接字的进程。将barrier_wait实现为：
open connection to barrier process
send message telling barrier process I am waiting
block in read() waiting for reply
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初始化为等待屏障的线程数。
然后barrier_destroy将是：
lock(master_mutex);
time_to_die = true;
bool do_release = waiter_count == 0;
unlock(master_mutex);
if (do_release)
release_resources();
关于信号处理等所有细节，我不是很确定……但“最后一个离开的人熄灯”这个基本想法是可行的，我认为。
pthread_barrier_destroy函数只与最后一个等待者同步。那么问题是什么呢？ - Hasturkunpthread_barrier_destroy获取锁，确保销毁成功时没有人访问屏障内部（如果有任何线程正在等待，则不会成功）。 - Hasturkun