Esta pregunta se basa en:

¿Cuándo es seguro destruir una barrera de hilo?

y el reciente informe de error de glibc:

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

No estoy seguro sobre el problema de semáforos reportado en glibc, pero presumiblemente se supone que es válido para destruir una barrera tan pronto comopthread_barrier_wait devuelve, según la pregunta vinculada anterior. (Normalmente, el hilo que obtuvoPTHREAD_BARRIER_SERIAL_THREAD, o un hilo "especial" que ya se consideraba "responsable" del objeto barrera, sería el que lo destruiría.) El principal caso de uso que puedo pensar es cuando se usa una barrera para sincronizar el uso de un nuevo hilo de datos en la pila del hilo de creación, evitando que el hilo de creación vuelva hasta que el nuevo hilo use los datos; otras barreras probablemente tengan una vida útil igual a la de todo el programa, o controladas por algún otro objeto de sincronización.

En todo caso,cóm puede una implementación garantizar que la destrucción de la barrera (y posiblemente incluso la desasignación de la memoria en la que reside) sea segura tan pronto comopthread_barrier_wait vuelve en cualquier hilo? Parece que los otros subprocesos que aún no han regresado necesitarían examinar al menos una parte del objeto de barrera para finalizar su trabajo y regresar, como en el informe de error de glibc citado anteriormente,sem_post tiene que examinar el recuento de camareros después de haber ajustado el valor del semáforo.