I have a single queueset, which multiple tasks have access to, and I’m having an issue where a single doesn’t allow other tasks to access the queueset. All of my tasks have the same priority and the only way I can get around this is to introduce a slight delay between multiple tasks accessing the queueset. Without the delay I mentioned, all tasks do not have any delays and the only blocking call is the queueset itself.
Could the constant access to the queueset from multiple tasks without any delays, introduce the issue of task starvation?
I would be grateful if you can provide more details about what you are trying to do and the issue you are seeing. For example, as far as I recall you should be able to access a queue set from more than one task as the queue set is, itself, just a queue - and it has always been safe to read from a queue from multiple tasks. If the queue set is empty then the tasks will block on the queue set just as they would when blocking on a task. Is this what you are trying to do? If so, do you use a block time? What behaviour are you seeing that is not expected?
I suspect that even if you have other tasks of the same priority waiting on the queue set, that if the first task to take an item processes the item and comes back to the queue set without ever blocking or yielding if another item arrives before it is done processing, then it will take it.
The issue is that when the item arrived at the queue set, another task may have moved from blocked to ready, but until the current task blocks or yields, it won’t be able to actually take the item, that requires the task actually make it to the Running state. Time slicing might not help, unless a tick interrupt occurs after the next item arrives and while the first task is still processing, so there is an item in the queue for the next task.