kernel: queue length functions #95584
Conversation
Add functions for querying the number of elements currently pending on a `k_lifo`, `k_fifo`, or `k_queue`. These are instantaneous measures that may be incorrect by the time the function returns, i.e. the same behaviour as the `_is_empty` functions. Signed-off-by: Jordan Yates <[email protected]>
Add tests for `k_fifo_len`, `k_lifo_len` and `k_queue_len`. Since the implementations defer directly to `sys_sflist_len`, we don't need to be exhaustive in our test cases, as the latter is already tested. Signed-off-by: Jordan Yates <[email protected]>
Document the new queue length functions. Signed-off-by: Jordan Yates <[email protected]>
JordanYates
force-pushed
the
250906_queue_len
branch
from
de7126c to
4f75060
Compare
|
|
Not sure whats going on with the failing tests, they only fail on the x86 QEMU platforms but they pass fine locally for me. I can't see how anything I do on my dedicated queue would affect the failing test. |
|
It is not immediately obvious to me why the test test_lifo_nowait() is failing on qemu_x86. However, I have two concerns with the implementation of k_queue_len(). This first is that it is O(n) and scales linearly. The second (and greater concern) is that the queue is not locked while traversing it which can lead to corruption of the list if it gets preempted. If you need the count/length of the queue, might it be worthwhile to use a wrapper that increments/decrements the count as items are added/removed? There would be a small extra cost incurred each time an item is added or removed, but getting the count/length would be O(1). |
Add functions for querying the number of elements currently pending on a
k_lifo,k_fifo, ork_queue. These are instantaneous measures that may be incorrect by the time the function returns, i.e. the same behaviour as the_is_emptyfunctions.These are simple wrappers around
sys_sflist_len.The intent is to provide a function to query the number of
net_buf's currently free in a pool, and the pools utilize these queues internally.