unknowcoder wrote on Sunday, March 25, 2018:
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.
rtel wrote on Sunday, March 25, 2018:
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.
unknowcoder wrote on Monday, March 26, 2018:
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.
richard_damon wrote on Monday, March 26, 2018:
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.
unknowcoder wrote on Monday, March 26, 2018:
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.
richard_damon wrote on Monday, March 26, 2018:
Yes, you only need a mutex if you might have an access conflict on one side.
rtel wrote on Monday, March 26, 2018:
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.