Re: libc recently more aggressive about pthread locks in stable ?

[Gert Wollny <gw.fossdev@gmail.com>]

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