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.
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.