Willy Tarreau a1ecbca0a5 BUG/MINOR: freq_ctr/threads: make use of the last updated global time ... The freq counters were using the thread's own time as the start of the current period. The problem is that in case of contention, it was occasionally possible to perform non-monotonic updates on the edge of the next second, because if the upfront thread updates a counter first, it causes a rotation, then the second thread loses the race from its older time, and tries again, and detects a different time again, but in the past so it only updates the counter, then a third thread on the new date would detect a change again, thus provoking a rotation again. The effect was triple: - rare loss of stored values during certain transitions from one period to the next one, causing counters to report 0 - half of the threads forced to go through the slow path every second - difficult convergence when using many threads where the CAS can fail a lot and we can observe N(N-1) attempts for N threads to complete This patch fixes this issue in two ways: - first, it now makes use og the monotonic global_now value which also happens to be volatile and to carry the latest known time; this way time will never jump backwards anymore and only the first thread updates it on transition, the other ones do not need to. - second, re-read the time in the loop after each failure, because if the date changed in the counter, it means that one thread knows a more recent one and we need to update. In this case if it matches the new current second, the fast path is usable. This patch relies on previous patch "MINOR: time: export the global_now variable" and must be backported as far as 1.8.		2021-03-17 19:36:15 +01:00
..
haproxy	BUG/MINOR: freq_ctr/threads: make use of the last updated global time	2021-03-17 19:36:15 +01:00
import	BUG/MINOR: xxhash: make sure armv6 uses memcpy()	2021-02-04 17:14:58 +01:00