En un comentario sobre la pregunta.Liberar automáticamente mutex en bloqueos en Unix en 2010, jilles afirmó:

Las sólidas mutexes de glibc son tan rápidas porque glibc toma atajos peligrosos. No hay garantía de que el mutex aún exista cuando el kernel lo marque como "causará EOWNERDEAD". Si se destruyó la exclusión mutua y la memoria fue reemplazada por un archivo asignado en la memoria que contiene la ID del último hilo propietario en el lugar correcto y el último hilo finaliza justo después de escribir la palabra de bloqueo (pero antes de eliminar completamente la exclusión mutua de su lista de propiedad mutexes), el archivo está dañado. Las sólidas mutexes de Solaris y will-be-FreeBSD9 son más lentas porque no quieren correr este riesgo.

No puedo entender el reclamo, ya que destruir un mutex no es legal a menos que esté desbloqueado (y, por lo tanto, no esté en la lista sólida de ningún hilo). Tampoco puedo encontrar ninguna referencia buscando un error / problema de este tipo. ¿Fue la afirmación simplemente errónea?

La razón por la que pregunto y me interesa es que esto es relevante para la corrección de mi propia implementación basada en la misma primitiva de mutex de Linux.