Willy Tarreau 3801bdc3fc BUG/MEDIUM: shctx: really check the lock's value while waiting ... Jérôme reported an amazing crash in the spinlock version of _shctx_wait4lock() with an extremely high <count> value of 32M! The root cause is that the function cannot deal with contention on the lock at all because it forgets to check if the lock's value has changed! As such, every time it's called due to a contention, it waits twice as long before trying again and lets the caller check for the contention by itself. The correct thing to do is to compare the value again at each loop. This way it makes sure to mostly perform read accesses on the shared cache line without writing too often, and to be ready fast enough to try to grab the lock. And we must not increase the count on success either! Unfortunately I'd have expected to see a performance boost on the cache with this but there was absolutely no change, so it's very likely that these issues only happen once in a while and are sufficient to derail the process when they strike, but not to have a permanent performance impact. The bug was introduced with the shctx entries in 1.5 so the fix must be backported to all versions. Before 1.8 the function was called _shared_context_wait4lock() and was in shctx.c.		2020-05-01 13:29:14 +02:00
..
common	BUG/MINOR: debug: properly use long long instead of long for the thread ID	2020-05-01 12:26:03 +02:00
import
proto	BUG/MEDIUM: shctx: really check the lock's value while waiting	2020-05-01 13:29:14 +02:00
types	CLEANUP: checks: Fix checks includes	2020-04-29 13:32:29 +02:00