Как можно разрушить барьеры, как только вернется pthread_barrier_wait?

Этот вопрос основан на:

Когда безопасно разрушать барьер pthread?

и недавний отчет об ошибке glibc:

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

Я не уверен в проблеме семафоров, о которой сообщается в glibc, но предположительно она должна быть действительной для уничтожения барьера, как только pthread_barrier_wait вернется, согласно связанному выше вопросу. (Обычно поток, который получил PTHREAD_BARRIER_SERIAL_THREAD , или «специальный» поток, который уже считал себя «ответственным» за объект барьера, должен уничтожить его.) Основной вариант использования, который я могу придумать. это когда барьер используется для синхронизации использования данных новым потоком в стеке создаваемого потока, предотвращая возврат создаваемого потока до тех пор, пока новый поток не сможет использовать данные; другие барьеры, вероятно, имеют время жизни, равное времени жизни всей программы, или управляются каким-либо другим объектом синхронизации.

В любом случае, как реализация может гарантировать, что разрушение барьера (и, возможно, даже отключение отображения) памяти, в которой он находится) безопасен, как только pthread_barrier_wait возвращается в любом потоке? Кажется, что другие потоки, которые еще не вернулись, должны будут проверить хотя бы некоторую часть барьерного объекта, чтобы завершить свою работу и вернуться, подобно тому, как в приведенном выше отчете об ошибке glibc sem_post должен проверьте количество официантов после корректировки значения семафора.