Why message buffer is not thread safe?

Just a personnal interrogation here :

Freertos doc states that message buffers (and stream buffers too) are okay to use for a one-task to one-task (or isr) scenario. Its stated too that contrary to the rest of freertos api, it’s not permited to write/read from multiple tasks without proper locking mechanism.

I aint got problem with that, but still I can’t help but ask myself as to why message/stream buffer was writen like that? Why not be consistent with the rest of the api?

Thanks!

It is done for speed and small code size efficiency. Stream/Message buffers are basically lock less, hence can only be read from by a single task or interrupt, and written to from a single task or interrupt. They are designed to cover the most common use cases, such as an interrupt service routine that always sends data to the same task so doesn’t benefit from the overhead introduced by more heavy weight primitives.

In my experience, it isn’t that big of a problem, as I tend to normally only have one task at the receiving end of most queue/streams, and I can use a mutex to protect the sending end if needed (you could also have one on the receiving end if you wanted to). The limitation isn’t only one, but one at a time (i.e. if one task is waiting on the stream, another task can’t access that same end).

Got it, thanks guys. Locking the stream/buffer was left to the prorgammer if need be in order to have lighter implementation.