stream_buffer: require batching buffers to exceed the trigger level#1396
stream_buffer: require batching buffers to exceed the trigger level#1396officialasishkumar wants to merge 1 commit intoFreeRTOS:mainfrom
Conversation
|
Changes look good though a rebase is needed. Please update your PR to contain the latest commits from the main branch. I did leave a conceptual comment on #1375. We can greatly simplify code changes by having the batching buffer trigger when data equals the threshold rather than exceeding the threshold. This is probably a breaking change though so your fix here is best. |
|
I've raised #1406 which is the counterpart to your PR. Let me know your thoughts. I'm in favor of simplify the number of conditionals required by better aligning existing stream buffer behavior - though your change is the correct one if we want to keep the existing threshold behavior. |
Batching stream buffers are documented to unblock receivers only after the buffered byte count exceeds the trigger level, but both xStreamBufferSend() paths currently notify as soon as the count reaches it. That equality case wakes the blocked receiver too early, causing xStreamBufferReceive() to return 0 bytes while the buffer still holds exactly trigger-level data. Route both task and ISR send paths through a shared trigger helper so batching buffers require a strict greater-than check while existing stream and message buffer semantics remain unchanged. Fixes FreeRTOS#1375 Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>
officialasishkumar
force-pushed
the
fix/stream-batching-trigger-threshold
branch
from
a651081 to
4df89dc
Compare
|
Rebased onto current |
|
2 participants
Description
Batching stream buffers are documented to unblock receivers only after the buffered byte count exceeds the trigger level. Both
xStreamBufferSend()andxStreamBufferSendFromISR()currently notify as soon as the count reaches that level, which wakes a blocked receiver too early and can makexStreamBufferReceive()return0bytes while the buffer still holds exactly trigger-level data.This change routes both send paths through a shared helper so batching buffers require a strict greater-than check, while stream and message buffers keep their existing trigger semantics.
Test Steps
FreeRTOS/Test/CMock/stream_buffer/apiharness against the updatedFreeRTOS-Kernelworking tree.Checklist:
Related Issue
#1375
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.