Can Streambuffer be used in critical section?

zhaojer wrote on Thursday, March 21, 2019:

I see the following content in the manual, are these two paragraphs contradictory?

Manual P365
If there are to be multiple different writers then the application writer must place each call to a writing API function (such as xStreamBufferSend()) inside a critical section and use a send block time of 0.

Manual P59
FreeRTOS API functions must not be called from within a critical section.

richarddamon wrote on Thursday, March 21, 2019:

Both those statements are in my mind a bit simplified.
First, Streambuffers don’t need a critical section, but do need some form of protection that you NEVER have multiple tasks trying to read or write the buffer at a given time. A critical section is one simple way to do this, having a Mutex protect the access should also work (and that gets around the need for 0 block time.

Second, the limitiation isn’t so much that they can’t be called from a critical section, but that no FreeRTOS API call should block or attempt to change the running task inside a critical section. (some ports actually don’t have a problem with it, but some do).

zhaojer wrote on Thursday, March 21, 2019:

First ,thank you much! But before that, I used Mutex protected, but every time I call the function (such as StreambufferSend) very slow, almost once every second. So i check the manual .

rtel wrote on Thursday, March 21, 2019:

What is it you are trying to do?

Stream buffers are designed to have one reader, and one writer. If you
use them in that scenario then you don’t need any protection. If you
want to go outside of their intended use then consider a queue instead,
but with some understanding, you may be able to have multiple readers
or multiple writers with a critical section or a semaphore, but you must
then never attempt to block on the stream buffer (hence comment about
having a block time of 0). If you lock a semaphore and then block, the
semaphore will remain locked. If you enter a critical section and then
attempt to block, you won’t switch to another task, and your application
will have run-time logic errors (task that is technically in the blocked
state is still actually running).

zhaojer wrote on Friday, March 22, 2019:

OK, I have know it, thank you.