Multi-Core: Solution or Problem?
We hear a lot of noise from the silicon manufacturers today about how multi-core processors are the wave of the future. Certainly, they do allow us to pack more performance into a single package. However, are they a good fit for embedded systems?One argument is that with two or more cores at a lower voltage, we can run with a lower thermal dissipated power envelope. This is certainly true. Power consumption can certainly be lower in certain applications. And, with multiple processors, the potential is certainly there for doing more work with less heat and power consumption.
However, although multiple cores can make good sense from a hardware perspective, they can be a real problem from a software perspective. There are basically two approaches for operating systems in a multi-core environment. One is to partition the cores and run two separate operating systems. This can allow you to mix OS variants so you could have say, an RTOS on one core and a something like Linux on the other for the user interface. Naturally, this complicates the communications between the cores and requires partitioning the memory and assigning certain devices such as PICs to one OS or the other. Essentially, this becomes two uniprocessors in the same physical package.
The other approach is to run an symmetric multi-processing (SMP)-aware operating system. Unfortunately, there aren't too many of these on the market just yet. VxWorks, Linux, QNX and maybe a couple of others. Running an SMP-aware OS can simplify some things such as load balancing. Interrupts and processes/threads can migrate from one core to another based on work load. This can be good. But, it can also be very bad.
The problem comes in when, say, two threads that would have normally run A then B on a uniprocessor due to priority preemption, suddenly run simultaneously on both cores. The potential for race conditions is rampant. We must make sure that our code is not only logically correct, but temporally correct as well.
Consequently, running on multiple cores requires a significant amount of thought on the part of the software designer. The use of synchronization primitives to ensure proper sequencing is imperative. This is especially true for operating systems like Linux that can schedule different threads from the same process on different cores simultaneously.
In order for us to get the most from a multi-core system, we need to take advantage of the blocking side-effects of certain primitives such as message queues and semaphores to make sure that we run not only the correct code, but the correct code at the correct time. This will require a significant amount of forethought on the part of the designer. This is also why so many SMP-type multi-core solutions will be buggy or fail entirely.
There is no silver bullet here. No language extensions or class libraries will save us from ourselves. We, as designers, must take the time to understand the nature of SMP and learn the proper use of synchronization primitives and how to enforce sequencing of code on multiple cores. Fortunately, with the availability of Intel's Core 2 Duos, multi-core test hardware is relatively cheap. Unfortunately, there are no texts or classes that teach how to write good, multi-core code. For the time being, experience will be the primary teacher.
So, if you believe that you're going to be writing multi-core aware applications in your future, you've got to get on multi-core hardware and start testing your understanding of the environment. Look at processor/interrupt affinity issues and get up to speed on synchronization primitives such as message queues, binary/counting/mutual exclusion semaphores, and condition variables to understand how their use can change the interleaving of code.
Finally, pick up a core duo machine, install Linux and start playing with multi-threading code using the POSIX threading services. Also, plan on attending some of the sessions at the Embedded Systems Conference in April. There will be several sessions there that will help you understand the issues. A little time spent experimenting now will save you weeks of debugging later.
0 Comments:
Post a Comment
<< Home