I want to send some variables which are set in one task to multiple tasks. I read about queue and buffer but data in those mechanisms get deleted after first read.
Till now global variables seems to be the only way to do this.
Is there any other way to send some variables from one task to multiple tasks?
Well, do you want to send the values of some task local variables or do you want to share the variables itself and access them from multiple tasks ?
That’s fundamentally different and therefore requires different mechanisms to use.
I want to send the local varaibles of one task to multiple tasks.
I believe that the choices are either send the data on multiple queues (one for each task) or use a global variable.
If you just need to send an notification to multiple tasks, you can use an Event Group, and that could also be used for a small value.
It sort of an unusual need, and causes the issue of how would the system know that everyone who needed that value has got it so it could move to the next one.
Hi,
Have you consider trying:
BaseType_t xQueuePeek( QueueHandle_t xQueue,void *pvBuffer, TickType_t xTicksToWait );
and
BaseType_t xQueueOverwrite( QueueHandle_t xQueue, const void *pvItemToQueue );
1 Like
Go with what @jiuhao2019 recommended.
Make your queue a single entry, a mailbox.
Your producer puts the object in it using overwrite every time. Your consumer threads never pull, only peak.
This means at anytime your other threads can see the latest posting to the mailbox and get a copy of their own data, but it remains there for other threads to do the same.
The issue is your producer needs to update on change. And that your consumers aren’t able to block on this waiting for data because “a” message always exists here.
If you need to alert a consumer device of new data you can use notify to do so. You can even use the notify value where each bit aligns to a specific mailbox if you have multiples.
Note that the data in the queue is a copy. So you don’t want to make it overly large if you can help it, but it’s threadsafe.
1 Like
A single entry queue here is no better than a simple global buffer that the task copy their data in/out of with a critical section (like the queue code would use).
A single entry queue here is no better than a simple global buffer that the task copy their data in/out of with a critical section (like the queue code would use).
Except it’s built in, you can’t mess it up, you can keep commonality with existing or other queues in terms of how you use them. The producer could revoke the data form the consumers at any time by self-emptying the mailbox. You also wouldn’t need to be concerned with the potential that a consumer was 1/2 way through reading when interrupted by a producer who now had critical section to write new data, but I suppose this would only be an issue with interrupts or if you had time slicing, normal scheduling wouldn’t interrupt the consumer half-way during a read I suppose.
But yea, you lose the ability to wake tasks on it. I agree, you could code this yourself and save the 80 bytes per mailbox (single entitiy queue) overhead.