https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #13 from Paul Floyd <pjfl...@wanadoo.fr> --- Looking at the glibc source pthread_mutex_destroy is fairly simple. It does an atomic read of the kind and a plain read of nusers and returns EBUSY if nusers is not 0. It then sets kind to an invalid value, -1. pthread_mutex_unlock is a lot more complicated. It also does atomic reads of the kind, decrements nusers and checks the lock then does a cas on the lock. If I run with --default-suppressions=no then there huge numbers of hazards, but none related to pthread_mutex_destroy. I think that is because Helgrind sees the lock order is such that pthread_mutex_destroy is called in a serial section. -- You are receiving this mail because: You are watching all bug changes.
