这个问题基于:
和最近的glibc错误报告:
http://sourceware.org/bugzilla/show_bug.cgi?id=12674
我不确定glibc中报告的信号量问题,但据推测pthread_barrier_wait,根据上述相关问题,它应该在返回后立即销毁屏障.(通常,获得的线程PTHREAD_BARRIER_SERIAL_THREAD或已经认为自己对屏障对象"负责"的"特殊"线程将是销毁它的那个.)我能想到的主要用例是当使用屏障时同步新线程在创建线程堆栈上使用数据,防止创建线程返回,直到新线程使用数据为止; 其他障碍可能具有与整个程序相同的生命周期,或由其他一些同步对象控制.
在任何情况下,只要在任何线程中返回,实现如何确保屏障的破坏(甚至可能是它所驻留的内存的取消映射)是安全的pthread_barrier_wait？似乎尚未返回的其他线程需要至少检查屏障对象的某些部分才能完成其工作并返回,就像上面提到的glibc错误报告sem_post中调整服务员计数后的情况一样.信号量值.
在过去的一个问题中,我询问了如何在没有破坏竞赛的情况下实施pthread障碍:
一旦pthread_barrier_wait返回,障碍如何可以销毁？
并且从迈克尔伯尔那里得到了一个完美的流程局部障碍解决方案,但却因流程共享障碍而失败.我们后来研究了一些想法,但从未得出令人满意的结论,甚至没有开始陷入资源失败的情况.
是否有可能在Linux上构建满足这些条件的障碍:
迈克尔尝试解决流程共享案例(参见链接问题)有一个不幸的特性,即必须在等待时间分配某种系统资源,这意味着等待可能会失败.并且不清楚当障碍等待失败时调用者可以合理地做什么,因为屏障的整个点是在其余N-1线程到达之前继续进行是不安全的......
内核空间解决方案可能是唯一的方法,但即使这很困难,因为信号可能会中断等待而没有可靠的方法来恢复它...