Question: I'm developing a real-time system by making use of an mbed-OS (RTOS for ARM architecture). I'm not a software engineer and I want to know whether the following solution is practical or not, and how to improve it.

As it is shown in the figure, the elements of software are as follows:

Three different classes (ClassA, ...) describes low level peripherals for gathering data from three different modules which their instances are passed-by-reference to three different Threads (Thread a, ...).
By using three queues (queueA, ...), I'm sending data to the Thread d which is gathering data from the other 3 threads to combine them to form a string in a desired format (synthesis).
The combined data are queued to the Thread e and if some scenarios (Happening in the first three Threads) satisfied, that data is sent to the Thread g.
Now the questions are:

Three first threads are gathering data in different update rates; How to synchronize them in the Thread d?
What is the best signaling solution to aware the other threads (Event or Signal?!)
Is the mentioned architecture practical?
Thanks.

Block Diagram:
![block diagram](https://i.stack.imgur.com/R26FJ.png)

Answer: 
There is a level of priority that I feel like you have reversed. 

Typically, the software that communicates with the peripheral is the driver level and is the lowest level of abstraction. Drivers do not need to know anything about the logic or data above their level, only how to communicate with the peripherals and where to put the data.

Next above them is more of a manager level. This level communicates with the drivers to grab the data and do formatting, perform sorting, or any other type of algorithms.

Above them, is the application level. This level is typically used as overarching state manager or any "business" logic.

[![Embedded Software Architecture](https://i.stack.imgur.com/mgO3u.png)](https://i.stack.imgur.com/mgO3u.png)

Hardware interrupts are better equipped for handling low level peripherals, such as an ADC or comm device, instead of having an RTOS thread/task. Handling and servicing these interrupts is best handled at the driver level. So "threads" A, B, C would be interrupts from hardware interrupts.

Also, want to point out that I think you mean RTOS tasks, b/c threads can run concurrently and are not **typical** in embedded development.

As your data is coming in, you should have an event/message/flag/signal from the interrupt context to inform the manager task D, that the data is ready for that specific data type. This will keep the interrupt processing to a minimum and lessen the complexity of keeping your code synchronous safe.

A message queue would be best, so you have less fear of losing a message from one of your other peripherals as you are gathering the data from another one.

Another thing to keep in mind, is that you would want to disable the interrupt for the peripheral/driver that you are accessing the data for. Otherwise, you could be moving/copying data, when you receive an interrupt, that manipulates the data you are trying to access, which could corrupt it. Or you need to setup a FIFO circular buffer in the driver, where the interrupt only writes to it, while the manager only reads from it.

Task E would be at application level, waiting for an outside application to request the data, or it provides a service to transmit/broadcast the data for whomever the consumer is.

Im not sure I understand why you would need task F or G.

Sorry if this is a long winded answer, but embedded software architecture is a very large knowledge space.
Understood that the questioner is not a software engineer, but answering the question requires additional and different information that is likely only to be appreciated by a real-time engineer. 

The issues that matter from a real-time architecture perspective are the inbound data rates and data sizes and related issues in servicing the components providing the system with data (do they have buffers and deadlines?); scheduling characteristics of the CPU hardware; the way the OS handles priorities; tolerance for data loss; any deadlines in aggregation that this system has to meet, etc. 

In the real-time context, "threads" and "queues" is far too high level, one needs concrete numbers and components.