At the core, the use of threads for any embedded system required to operate in hard real time is a mistake. Threads and interrupts are the minefields of real-t

At the core, the use of threads for any embedded system required to operate in hard real time is a mistake. Threads and interrupts are the minefields of real-time embedded systems. Based on study and years of experience I conclude that the ONLY way to build such as system is to use a time-triggered approach as opposed to event-triggered. No threads. Only one interrupt --the timer-- in the entire system if at all possible. This is where I fall back to the raw simplicity of C. You really have to work hard to do stupid shit like threads in C. By that I mean that you have to go out of your way to bring in the code and a framework that might allow you to do that. I've successfully written and applied at least a couple of RTOS's for use in mission critical applications (definition: you fuck up and someone gets hurt or dies). Again, only one interrupt. No threads. Carefully --and I do mean very carefully-- shared data between tasks only if absolutely necessary. A corollary to this is that I could not fathom programming an electron microscope (the subject of the SO question) or anything that might lead to millions of dollars in losses with Java. Couldn't pay me enough. Anyone interested in working with hard real-time embedded systems would be wise to study the following well-known books: - Patterns for Time-Triggered Embedded Systems, Michael J. Pont - Embedded Systems Building Blocks, Jean J. Labrosse - uC/OS-III, Jean J. Labrosse (uC/OS-II by the same author includes the source to the prior version of the OS) - Doing Hard Time, Grady Booch - Operating System Concepts, Silbershatz, Galvin, Gagne There are other good books on the subject. The above should provide a very solid foundation. Don't just hack away without the necessary background. The consequences of making mistakes out of sheer ignorance could be dire.