mirror of
https://sourceware.org/git/glibc.git
synced 2025-11-24 12:21:09 +03:00
The support for lock elision was already deprecated with glibc 2.42: commit77438db8cf"Mark support for lock elision as deprecated." See also discussions: https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html This patch removes the architecture specific support for lock elision for x86, powerpc and s390 by removing the elision-conf.h, elision-conf.c, elision-lock.c, elision-timed.c, elision-unlock.c, elide.h, htm.h/hle.h files. Those generic files are also removed. The architecture specific structures are adjusted and the elision fields are marked as unused. See struct_mutex.h files. Furthermore in struct_rwlock.h, the leftover __rwelision was also removed. Those were originally removed with commit0377a7fde6"nptl: Remove rwlock elision definitions" and by chance reintroduced with commit7df8af43ad"nptl: Add struct_rwlock.h" The common code (e.g. the pthread_mutex-files) are changed back to the time before lock elision was introduced with the x86-support: - commit1cdbe57948"Add the low level infrastructure for pthreads lock elision with TSX" - commitb023e4ca99"Add new internal mutex type flags for elision." - commit68cc29355f"Add minimal test suite changes for elision enabled kernels" - commite8c659d74e"Add elision to pthread_mutex_{try,timed,un}lock" - commit49186d21ef"Disable elision for any pthread_mutexattr_settype call" - commit1717da59ae"Add a configure option to enable lock elision and disable by default" Elision is removed also from the tunables, the initialization part, the pretty-printers and the manual. Some extra handling in the testsuite is removed as well as the full tst-mutex10 testcase, which tested a race while enabling lock elision. I've also searched the code for "elision", "elide", "transaction" and e.g. cleaned some comments. I've run the testsuite on x86_64 and s390x and run the build-many-glibcs.py script. Thanks to Sachin Monga, this patch is also tested on powerpc. A NEWS entry also mentions the removal. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>