stream_buffer: require batching buffers to exceed the trigger level#1396
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. |
officialasishkumar
force-pushed
the
fix/stream-batching-trigger-threshold
branch
from
a651081 to
4df89dc
Compare
|
Rebased onto current |
|
kstribrnAmzn
force-pushed
the
fix/stream-batching-trigger-threshold
branch
from
4df89dc to
d0a3bc6
Compare
|
Accepting your PR since this preserves the behavior that the user would expect per documentation. In the future, as in when the next major Kernel release is done, I'll back out this change and replace it with #1406 to reduce code. |
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>
kstribrnAmzn
force-pushed
the
fix/stream-batching-trigger-threshold
branch
from
d0a3bc6 to
3030587
Compare
|
|
The only failing check (WIN/MSVC) was failing due to an ARM gitlab repo. This PR does not impact this. Approving. |
3 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.