Concurrency and Parallelism
What approaches can I use to leverage the power of multi-core processors while ensuring synchronization and preventing race conditions in RTOS applications?
TFrom @jeanlabrosse_92110, creator of the Micrium RTOS:
This is a very broad question and complicated to answer. There are different types of multicores. Same core types or different core types. If you have a multicore with the same core (i.e. homogenous) then I’d say get an RTOS from a company that supports this type of chip. I assume you are not trying to design your own multicore RTOS because, it’s a lot harder than you’d think. The RTOS, in the case of an homogeneous multicore takes care of the synchronization and helps prevent race conditions. You still have to make design decisions such as: do you set the affinity of certain tasks/processes to specific cores? How do you distribute the interrupts? How do you set priorities? etc. In such an RTOS, there is one RTOS that manages the multiple cores. From the user’s perspective you don’t see much of a different environment w/r to RTOS API calls as the RTOS takes care of allocating CPUs to tasks.
If you have a different cores then you will most likely run an RTOS on each core and communicate between them using shared memory and some synchronization mechanism using spin locks, hardware semaphores, triggering an interrupt on the destination core, etc. You would typically have one or more cores handle I/Os and one or more cores handle the application code. As a general rule, you want to reduce the amount of interaction between the cores. For example, I designed a system in the past that was dedicated to manage all the I/Os. I needed to read and scale 96 analog inputs, 24 analog outputs, read and debounce 240 switch inputs and control 160 relays. So, this CPU was doing all of the work and placing the ‘engineering units’ of the analog values in a large table that could be accessed by the application processor. If I was reading a temperature, the thermocouple was read and the temperature value was deposited in that table. The same concept applied for the other I/O types. As long as I could update everything 50 times per seconds, I was fine. Of course, this model doesn’t apply to every application but the I/O processor can manage an Ethernet controller (maybe the whole TCP/IP stack), USB controller, etc.
This is a very broad question and complicated to answer. There are different types of multicores. Same core types or different core types. If you have a multicore with the same core (i.e. homogenous) then I’d say get an RTOS from a company that supports this type of chip. I assume you are not trying to design your own multicore RTOS because, it’s a lot harder than you’d think. The RTOS, in the case of an homogeneous multicore takes care of the synchronization and helps prevent race conditions. You still have to make design decisions such as: do you set the affinity of certain tasks/processes to specific cores? How do you distribute the interrupts? How do you set priorities? etc. In such an RTOS, there is one RTOS that manages the multiple cores. From the user’s perspective you don’t see much of a different environment w/r to RTOS API calls as the RTOS takes care of allocating CPUs to tasks.
If you have a different cores then you will most likely run an RTOS on each core and communicate between them using shared memory and some synchronization mechanism using spin locks, hardware semaphores, triggering an interrupt on the destination core, etc. You would typically have one or more cores handle I/Os and one or more cores handle the application code. As a general rule, you want to reduce the amount of interaction between the cores. For example, I designed a system in the past that was dedicated to manage all the I/Os. I needed to read and scale 96 analog inputs, 24 analog outputs, read and debounce 240 switch inputs and control 160 relays. So, this CPU was doing all of the work and placing the ‘engineering units’ of the analog values in a large table that could be accessed by the application processor. If I was reading a temperature, the thermocouple was read and the temperature value was deposited in that table. The same concept applied for the other I/O types. As long as I could update everything 50 times per seconds, I was fine. Of course, this model doesn’t apply to every application but the I/O processor can manage an Ethernet controller (maybe the whole TCP/IP stack), USB controller, etc.
