joe_her wrote on Thursday, September 24, 2015:
Can I wait for the same queue msg in two different tasks? That is one task sends a msg, which shuold be recieved by two or more then one task. How can this be done? the main concern is who will clear the queue, and how can one make sure that the queue is cleard only after all “clients” got the messege?
I am a bit confused on this.
Thnaks
rtel wrote on Thursday, September 24, 2015:
Maybe each task could use xQueuePeek() to read the message from the queue without removing the message from the queue, and then set a bit in an event group to indicate that that task had obtained the message. When the value returned from xEventGroupSetBits() indicates that all the tasks had read the message then the message can be removed from the queue.
Just one suggestion - there are probably other methods that could be used too.
joe_her wrote on Thursday, September 24, 2015:
Thanks, but isnt there a racing risk? it looks like taskENTER_CRITICAL should be used between Peek and setting the bit. So I wonder if there is a better, more elegant, way.
rtel wrote on Thursday, September 24, 2015:
You should not call the peek function from a critical section, at least,
not if a block time is specified.
I would need to know more about the use case to know if a race condition
existed, as it would depend on what the tasks that had read from the
queue did next. If they were to immediately try reading again then they
too would have to check the event group to ensure all the tasks had read
the message before they tried reading again.
It also depends on the characteristics of how the queue is used. If
there is only one item available then you might implement a scheme where
by tasks subscribe to the message, then when a message arrives on the
queue it is sent to the tasks individually, maybe even using a task
notification.
joe_her wrote on Thursday, September 24, 2015:
Thnaks.
Will try that. As each event bit will be set by a different task, I think there is no risk of a race condition, assuming that setting the event bit is atomic, and this read-modify-write can not be interrupted by another task.
Johanan
richard_damon wrote on Thursday, September 24, 2015:
My general feeling is that if it is only two tasks, and they don’t need to keep ‘in sync’ while processing messages from the queue, that it would be much simpler to just create two queues and have the sender place the message on both.
If it is something more complicated, then maybe a better description would help.
joe_her wrote on Thursday, September 24, 2015:
Aha… that’s the simple solution.
Why didn’t I think of that??? 
Thanks