4
\$\begingroup\$

Hardware multithreading is common in personal computers (most Intel x86 systems support two threads per core), servers (POWER7, 4 threads per core; SPARC T5, 8 threads per core; SPARC64 VII+, 2 threads per core; Itanium 9500, 2 threads per core; and Intel's x86), network processors (commonly with 4 threads per core), and even the earlier version of Intel's Atom (2 threads per core), but multithreading seems to be noticeably less common in embedded systems outside of networking.

While MIPS developed a Multithreading Application Specific Extension specifically for embedded systems where equivalent multicore implementations would require licensing more core designs, use more chip area, and be less flexible in certain respects, it is not obvious that such has been broadly used. (The white paper "Optimizing Performance, Power, and Area in SoC Designs Using MIPS® Multithreaded Processors" offers an overview of some arguments in its favor, but one must consider the source.)

(Of course, most embedded systems do not advertise such details, but it seems from my very limited exposure that multithreading is not broadly used.)

One might consider various shadow (or banked) register mechanisms as very limited forms of switch-on-event-multithreading (SoEMT). The more common presence of such mechanisms makes it even more strange that even SoEMT is not adopted.

Obviously, multithreading would not be attractive for all uses. The trade-offs associated with shared versus dedicated resources would apply. (A shared resource can be more flexibly allocated to different users, but sharing may sacrifice optimization by specialization opportunities and tends to require better handling of contention. For energy use, the trade-offs for multithreading versus multicore, especially heterogenous multicore, can be complex and workload-dependent.)

Since many embedded systems have well-defined resource requirements and many have real-time performance requirements (both of which can reduce advantages from more flexible resource allocation), multithreading might not be especially attractive for such systems. Even the mindset of embedded system designers might slightly unjustly bias choices away from flexibility.

(Note that a multithreaded core does not require that tasks be multithreaded, though an OS would be required to guard against race conditions in its own data. On the positive side, with the sharing of local memory/L1 cache, locks would have lower overhead than with multiple cores. Alternatively, one could have one OS per hardware thread. Also, the general multithreading concept can support a variety of scheduling alternatives from fixed slot allocation through as-ready execution to dynamically weighted scheduling with multiple weight factors.)

I also suspect that lack of familiarity with the hardware implementation (and validation) of multithreading and with the use of such hardware may also be holding back adoption. Even with a mature software development infrastructure, multithreading might inherently add more complexity (with development and reliability costs) than benefits in other areas.

For microcontrollers, simple pipelines and predictable memory access delay would reduce the benefit of interleaved multithreading. In addition, the fraction of chip area used for the core is so small (and the licensing costs might be tiny and per licensed design not per instantiation) that adding multithreading might not be attractive relative to adding more identical cores; adding multithreading is much less costly in area than adding cores. (Coding closer to the metal, as is more common there, would also discourage diversity in core types much less dynamic diversity in performance.)

Are the above the only reasons that multithreading is not more common in embedded systems? What changes could make multithreading more common in embedded systems?

\$\endgroup\$

closed as primarily opinion-based by Daniel Grillo, Gustavo Litovsky, placeholder, The Photon, Dave Tweed Oct 18 '13 at 20:39

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ The fact that there is not a multithreading tag (much less hardware-multithreading tag) seems to confirm that multithreading is not common. (Please do forgive/correct the weak tagging.) \$\endgroup\$ – Paul A. Clayton Oct 18 '13 at 17:22
  • \$\begingroup\$ I'm not exactly clear what you're asking. Are you suggesting that you'd like to see something like a processor which has two sets of registers and switches between them each cycle? I've certainly seen some cases where such a thing could be nice, and from a hardware-design standpoint it should be relatively cheap (registers which are normally loaded--with either their old value or a new one--every cycle could be "doubled" up by simply adding a D-flop after each one). I'm not sure such a thing would be good from an energy/performance standpoint, however. \$\endgroup\$ – supercat Oct 18 '13 at 18:09
  • 1
    \$\begingroup\$ You say it well yourself: "Since many embedded systems have well-defined resource requirements and many have real-time performance requirements (both of which can reduce advantages from more flexible resource allocation), multithreading might not be especially attractive for such systems..." Add into that thread-unsafe operations necessitating locks and so-on is overcomplicating things. occam's razor \$\endgroup\$ – HL-SDK Oct 18 '13 at 18:22
  • \$\begingroup\$ @supercat See en.wikipedia.org/wiki/… for a description. Multiple contexts (registers, PC, etc.) are provided and hardware handles "context switches"; such can look to software very much like multiple cores but shares more resources among "virtual cores" than multiple cores typically would. \$\endgroup\$ – Paul A. Clayton Oct 18 '13 at 18:23
  • \$\begingroup\$ @HL-SDK Many uses would not require significant locking, and the comparison is to multicore (likely heterogenous) or a single beefy core that must have software-managed context switches at sufficiently fine granularity to provide adequate responsiveness. \$\endgroup\$ – Paul A. Clayton Oct 18 '13 at 18:28
3
\$\begingroup\$

In embedded systems, raw processor throughput is not normally as important as determinism; predictable behaviour that can be validated. Multithreaded code is much harder to make deterministic.

It's also only running a single application with a few simple tasks, so multithreading is less of a benefit.

If you need multithreading and more processor power, then some of the medium sized ARM cortex processors start to be very suitable to this.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.