> On 14 Sep 2026, at 23:40, David Laight <[email protected]> wrote:
[snip]
> If you split the 'long counter' into a separate array then it won't
> be in the same cache line as the associated lock.
> That should mean the alignment changes aren't needed.
Yes. I tested that, and the module finds the same "errors". A good
simplification.
>
> When I mentioned a delay in the RMW for xxx->counter++ I was thinking
> of a few clocks, perhaps something like:
> c = xxx->counter;
> for (auto i = c + 10; i != c; i--)
> OPTIMIZER_HIDE_VAR(i);
> OPTIMIZER_HIDE_VAR(i);
> xxx->counter = i + delta;
For the lock-full cases, there are already some instructions to be
executed, the return from mx_acquire(), the call to mx_add(), and
the beginning of mx_release(). So, I am reluctant to add further
delays, unless it can be proven useful for better error detection.
I also looked into your statement that the default number of
locks/counters was too high. I compiled the table below from empirical
testing on a 160-CPU Arm bare-metal system.
For each element count, I ran the test 100 times, with each run
lasting one second. I used the "osq_lock_busted" test which is
the failing test that is least likely to fail.
#elements percent failures
===================================
1024 90
2048 95
4096 92
8192 94
16384 85
32768 79
65536 66
Hence, I yanked the default *up* to 2048.
Thxs, Håkon
