Hi, I was looking to begin using the new StreamBuffer interface in the future, but the use of xTaskNotifyWait within xStreamBufferSend / xStreamBufferReceive looks problematic for integration with the rest of our system. We use task notifications to set a range of event flags, with the body of most tasks consisting of an infinite loop that blocks forever on a xTaskNotifyWait, followed by testing the bits in the notification value and performing actions if they’re set. Sure, we could use global flags instead, but why bother if we have task notifications? Anyways, the stream_buffer.c xTaskNotifyWait calls appear to clear all notification value bits, even though the xTaskNotify calls don’t set any bits. I can’t really see any downsides to not clearing these bits and preserving this information for other parts of the system to use. Maybe I’m missing something? Sure, there are additional complications to sharing the task notifications this way: I’d probably have to use a loop and xTaskCheckForTimeOut to call xStreamBufferReceive until I have the desired number of bytes just in case one of my other task events were set during a read from a stream buffer, but I already have equivalent code for this in my UART drivers to handle waiting for any number of ISRs to finally receive the number of bytes I’m looking for.
Are you suggesting having the stream buffers set and clear a single bit, rather than the entire event group. Would that work for you, assuming the bit didn’t clash with a bit you were already using?
Hi Richard, thanks for the quick reply. I am suggesting that no bits be used. The implementation currently uses xTaskNotify with eNoAction to unblock the waiting task, conveying this information through ucNotifyState instead of ulNotifiedValue. The blocked tasks, however, call xTaskNotifyWait with a request to clear all bits in ulNotifiedValue on exit. Changing that to not clear any bits would permit the regular use of task notifications alongside stream buffers. As far as I can tell, the exception is eSetValueWithoutOverwrite, which wouldn’t work because it uses ucNotifyState which would be modified by the stream buffer, but the others (like my use of eSetBits) would work fine. The stream state is checked again after unblocking, so there’d be no harm in receiving a notification outside of the stream buffer interface.
Ok – I’ve made this change, but not checked it in yet as I need to test it and consider any unintended backward compatibility consequences.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.