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?