一旦pthread_barrier_wait返回，障碍如何可以销毁？

Question

这个问题基于：

When is it safe to destroy a pthread barrier?

以及最近的glibc错误报告：

http://sourceware.org/bugzilla/show_bug.cgi?id=12674

我不确定glibc中报告的信号量问题，但根据上面的链接问题，一旦pthread_barrier_wait返回，我认为它应该是有效的。 （通常，获得PTHREAD_BARRIER_SERIAL_THREAD的线程或者已经认为自己对屏障对象“负责”的“特殊”线程将是销毁它的那个。）我能想到的主要用例是屏障用于同步新线程在创建线程堆栈上使用数据，防止创建线程返回，直到新线程使用数据为止;其他障碍可能具有与整个程序相同的生命周期，或由其他同步对象控制。

在任何情况下，只要pthread_barrier_wait在任何线程中返回，实现就可以确保实现确保屏障的破坏（甚至可能取消映射它所驻留的内存）的如何是安全的？似乎尚未返回的其他线程需要检查屏障对象的至少某些部分才能完成其工作并返回，就像在上面引用的glibc错误报告中sem_post必须检查服务员在调整了信号量值后计算。

Answer 1

Answer 2

据我所知，pthread_barrier_destroy不需要立即行动。您可以等到所有仍处于唤醒阶段的线程都被唤醒。

例如，你可以有一个原子计数器awakening，它最初设置为被唤醒的线程数。然后它会在pthread_barrier_wait返回之前作为最后一个动作递减。 pthread_barrier_destroy然后就可以旋转直到该计数器降至0。