You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
samples: zbus: benchmark: Filter SMP from benchmark_sync test
The benchmark_sync test produces incorrect results on SMP systems due to
a race condition between the producer thread and subscriber threads that
only occurs with parallel execution.
Thread configuration:
- Producer thread: priority 5 (lower priority, runs later)
- Subscriber threads (8): priority 3 (higher priority, runs first)
Expected behavior on uniprocessor:
1. Producer publishes message
2. Subscriber immediately preempts producer (priority 3 < 5)
3. Subscriber processes message, calls atomic_add(&count, 256)
4. Producer resumes, continues to next message
Result: All messages counted before producer checks final count.
Race condition on SMP:
CPU 0 (Producer): CPU 1-3 (Subscribers):
----------------- ----------------------
Publish msg 1
k_msgq_put(sub1) ✓
k_msgq_get() → processing
Publish msg 2
k_msgq_put(sub2) ✓
k_msgq_get() → processing
...continues...
Publish msg 128 ✓
atomic_get(&count) Still processing...
→ Reports incomplete count! atomic_add() comes later
On SMP, the producer doesn't get preempted since it runs on a different
CPU from the subscribers. It races ahead and checks atomic_get(&count)
while subscriber threads on other CPUs are still processing messages.
Observed results:
- Non-SMP: Bytes sent = 262144, received = 262144 ✓
- SMP: Bytes sent = 262144, received = 260352 ✗ (7 messages lost)
This is a benchmark test design issue, not a zbus bug. The test assumes
subscribers complete before the producer finishes, which doesn't hold on
SMP systems. Filter SMP configurations from this test variant.
Fixes CI failures on Arm's FVP SMP configurations.
Signed-off-by: Nicolas Pitre <[email protected]>
0 commit comments