Sending and receiving data from two queues within one task

nasher128 wrote on Monday, September 02, 2019:

Hi all.

I’m trying to implement a messaging system (call this a broker) where clients (other tasks) can register their services and other tasks can subscribe or unsubscribe to these services. The broker’s job will have two main roles:

  1. Being able to subscribe and unsubscribe tasks who wish to receive events from other tasks.
  2. Iterate though the current mappings and submit a request to a task for its services and then route this to the correct tasks who has previously subscribed to this message. This willalways be continiously be executing

However, the only method I can think of to fufill the above is block on a queue and listen for tasks subscription/unsubsciptions 1) and have a timeout of say 1ms which will then perform the operation described in 2). This seems quiet hackish and is a queue timeout meant to be used in the above scenario.


richard_damon wrote on Monday, September 02, 2019:

First, I think we have a bit of an X-Y problem (see, as I am not sure that your broker task is the best solution. (It may be a form of solution used in a multi-process system where there is a lot of isolation between processes, but we don’t typically have that under FreeRTOS.)

I don’t see a real need for a seperate task to be responsible for this subscribing/unsubscribing task to events, this can easily be implemented as a simple function that a task calls that manipulate the data structures to implement this. That function would use a Mutex to hold exclusive access to the data structure while it is manipulating it.

I don’t quite understand the connection of the first to the second, as the first is talking about events, while the second is taking about services, unless you mean the events as service complete events, and you only activate services that have somebody connected to the event. If that is the case, just give each service providing task a semaphore, and when a task connects to an event, if it needs to it signals the semaphore to start the service running. The serivces when the generate their events, can see if they have anything more to do and if so go off and do it, otherwise the stop and wait on their semaphore.

No ‘Broker’ Task needed, Services and Clients directly communicate to each other, through a Broker interface that runs within each client/service.