]> git.ipfire.org Git - thirdparty/haproxy.git/commit
REORG: threads: extract atomic ops from hathreads.h
authorWilly Tarreau <w@1wt.eu>
Thu, 28 May 2020 13:29:33 +0000 (15:29 +0200)
committerWilly Tarreau <w@1wt.eu>
Thu, 11 Jun 2020 08:18:56 +0000 (10:18 +0200)
commit9453ecd6705b35bc58e14d455ea94e2eda5b4ea1
tree590e5659edffd6385151e3c4eb52ecc3b4e0f946
parent853b297c9b82e5db58826b07a4438c627b55b04c
REORG: threads: extract atomic ops from hathreads.h

The hathreads.h file has quickly become a total mess because it contains
thread definitions, atomic operations and locking operations, all this for
multiple combinations of threads, debugging and architectures, and all this
done with random ordering!

This first patch extracts all the atomic ops code from hathreads.h to move
it to haproxy/atomic.h. The code there still contains several sections
based on non-thread vs thread, and GCC versions in the latter case. Each
section was arranged in the exact same order to ease finding.

The redundant HA_BARRIER() which was the same as __ha_compiler_barrier()
was dropped in favor of the latter which follows the naming convention
of all other barriers. It was only used in freq_ctr.c which was updated.
Additionally, __ha_compiler_barrier() was defined inconditionally but
used only for thread-related operations, so it was made thread-only like
HA_BARRIER() used to be. We'd still need to have two types of compiler
barriers, one for the general case (e.g. signals) and another one for
concurrency, but this was not addressed here.

Some comments were added at the beginning of each section to inform about
the use case and warn about the traps to avoid.

Some files which continue to include hathreads.h solely for atomic ops
should now be updated.
include/common/hathreads.h
include/haproxy/atomic.h [new file with mode: 0644]
src/freq_ctr.c