I have some software architecture where multiple tasks A, B and C can request some kind of services from each other. Those services then depend on information from the outside that is received from another special task D. A, B, C can all request things from D as well, but D will only respond and not request itself. For this to work to my intention I currently use two message buffers per task. Message buffers b1 are for the inter-task-communication between A, B and C. The other message buffers b2 are for the communication with D. Again, A, B and C have their own b1s and b2s.
Now I experience funny things looking like buffer overflows. My suspicion is the following scenario:
E. g. task A requests something from D and blocks for the response from D on its own message buffer A.b2.
Now e.g. task B requests something from task A via message buffer A.b1, i.e. a message is sent to A.b1.
Since message buffers all use the task notification at index 0, I guess it is possible, that A.b2 is unblockedby B sending to A.b1 (without D having responded anything yet).
Do I understand this correctly?
Btw: When using task notifications directly, I already use task notification index 1 due to similar interferences/effects.
Yes, that sounds feasible as to what is happening. The message/stream buffer implementation predates the direct to task notification enhancement that introduced indexing - prior to that there was only one notification per task.
The code change necessary to enable your scenario should be relatively simple though - adding a member to the stream buffer structure that holds the task notification index to use with that stream buffer, and a utility API that sets that index, would allow code like this https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.5.1/stream_buffer.c#LL729C22-L729C37 to use the stored index.
Would you be able to create a pull request to that effect?
Hi Richard! Thanks for your immediate reply!
I surely could get familiar with how you develop on the FreeRTOS code base, though I have to admit that currently I’m a bit in doubt whether it’s not just time to move to a queue.
I have used message buffers basically for historical reasons (availability in my os abstraction layer). To be able to use the message buffers with multiple tasks, I have already protected them using a mutex as a workaround, with in turn is a queue afaik. So maybe it’s just time for me to move to queues? Right?
With that being said, I think it only makes sense to make the usage of stream/message buffers easier and more versatile by enhancing them with the *Indexed principle of the task notifications. xMessageBufferCreate(Static) should be the best place for this.
I fell across these problems when extending some older code base - it’s just so easy to overlook all the constraints and interferences of task notifications/message buffers once you have reached a certain “high level” of your code.