xStreamBufferSend() calling before scheduler starts with block time of 0

Hi, Is it safe to call the xStreamBufferSend() before the scheudler starts witha block time of 0? I also understand that the stream buffer can only have 1 writer and 1 reader. I would like to have to have multiple writers and 1 reader. If I mutex protect the writes will this solve the problem of multiple writers? I am using the stream buffer to stream bytes from multiple task to a single task where they get consumed.

xStreamBufferSend() calling before scheduler starts with block time of 0

If the call doesn’t block (zero block time as you say) AND if the call does not attempt to perform a context switch (which it shouldn’t as if the scheduler has not been started a task cannot be blocked on the stream buffer) then it SHOULD be ok – but note it is not a scenario that has been tested.

xStreamBufferSend() calling before scheduler starts with block time of 0

Hi Richard, Thanks for the response. Can you comment on the mutex protection for multi writer scenerio? That is I can I protect the stream buffer with a mutex to allow multiple writers.

xStreamBufferSend() calling before scheduler starts with block time of 0

I asked a similar question a while back, and as long at any given time only one thing will be attempting to read and only one attempting to write at a time (and a semaphore is a good way to do that), things will be fine.

xStreamBufferSend() calling before scheduler starts with block time of 0

Hi, Well only one task reads so I don’t need to mutex protect the reader according to the doxygen you can have single reader and single writer. But I have as single reader and multi writers. So I plan to only mutex protect the writer. Since only one task can call the reader it doesn’t need a mutex.

xStreamBufferSend() calling before scheduler starts with block time of 0

Yes, you only need a mutex if you might have an access conflict on one side.

xStreamBufferSend() calling before scheduler starts with block time of 0

The important thing is there can only be one task blocked on a read, or one task blocked on a write, at any one time. Unlike ‘heavier’ communication mechanisms, such as queues, stream buffers do not contain lists of blocked tasks.