Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes Holschuh: > > > > Unfortunately, when hardware lock elision support was added to glibc > upstream, libpthreads was *not* changed to properly assert() this > forbidden condition on the non-hardware-elision codepaths. Such an > assert() would have given us consistent behavior, thus flushing the > bugs out in the open... at the cost of a performance hit (I have no > idea how severe), and much screaming.
An alternative to find problems with (un-)locking should be to compile the program in question with -fsanitize=thread (on amd64) and run it. Unfortunately, in current unstable with thread sanitizer one might get #796246 (at least I had this). Best, Gert
