Commit fb6e3ea
Nicolas Pitre
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 for now.
Signed-off-by: Nicolas Pitre <[email protected]>1 parent 472c13f commit fb6e3ea
1 file changed
+4
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
46 | 46 | | |
47 | 47 | | |
48 | 48 | | |
49 | | - | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
50 | 53 | | |
51 | 54 | | |
52 | 55 | | |
| |||
0 commit comments