Confused by this sentence which about stream buffer in RMv10.0

Kernel
1

in rm v10.0, page365,
"It is safe for the writer and reader to be different tasks or interrupts, but, unlike other FreeRTOS objects, it is
not safe to have multiple different writers or multiple different readers. "
it says it can be different writer and reader, but can not be multiple. is this contradiction?

2

You can have one reader, not multiple (more than one) readers. Likewise you can have one writer, not multiple writers. The reader and the writer can be different tasks.

3

thank you for reply soon.
i am not sure whether you are Mr. Richard Barry. Thank you.
from your words. i got understand like this: for ex. my app create three tasks, taskA taskB taskC; and a stream buff. now an ISR is sender, at this app, can an only can A or B or C be a reciever. but not multiple (more than one) can be reciever both. am i got the right point as you mentioned. sir.

4

Only one task at a time can attempt to read from the stream buff. You can use a mutex (or other method) so that only one task is using it at any given time, but different tasks at different times.

5

Mr.Richard Damon
thank you for reply. now i got somewhat known. i will use stream buffer later to test and verify my understand.

6

A bit more information, hope it helps. A stream buffer has the following properties:

struct {
	char buffer[ SIZE ];
	volatile int writeIndex;
	volatile int readIndex;
};

When readIndex equals writeIndex, it means that he buffer is empty. writeIndex will either be equal to, or run ahead of readIndex.
One thing to notice: the buffer can only contain SIZE-1 items only.

The writer (a task or an ISR) will write to the stream by updating writeIndex. The variable writeIndex is not protected by a mutex, because there is only one writing instance. I.e. no chance of a congruent access.

The same can be said about readIndex, only one task (or ISR) is allowed to read from the buffer.

The advantage of this approach is that no mutex is needed, a reading task can just poll if data is available by testing writeIndex != readIndex. This testing won’t cause any task swap and it doesn’t need any protection of a mutex.

In the case of e.g. a serial driver, it can be handy if the driver notifies the reader when data are available for reading. This is up to the developer.