The duality of Threads and Events
Posted Feb 12, 2007 5:57 UTC (Mon) by HalfMoon
Parent article: Fibrils and asynchronous system calls
I basically agree with Ingo here. Been there, done that.
The underlying observation is not new; threads and events/state-machines are the two basic ways to express concurrency in an OS context. Why do so many folk have a hard time understanding IRQ handling? Because that's purely an event mechanism. Why do so many people (think they) like threads? Because they've been taught that the world is really single threaded, in all those intro programming courses, and most text books don't burst that bubble. Hardware designers work with state machines all the time, of course...
The classic problem of evolving an operating system so it scales up without losing performance can also be stated as: how do we move this pile of legacy crap more towards a primarily event-driven model?
Of course it's not like threads will ever vanish. They work hand in hand with event frameworks, the other side of the coin ... and no sane person will say "heads" is always better than "tails". But on the other hand, a large system with 10,000 threads crunching away inside of it is going to be more wasteful than the equivalent one with all those threads waiting at the periphery, while the insides are an event-driven state machine chewing away at the requests issued by those threads.
Remember: ten thousand thread/fibril/LWP/... stacks takes up a lot of memory (4K each), and the thing that makes them seem to be "easy to program" is in large part that critical system state is isolated on all those stacks. So when something goes wrong, it's almost completely invisible to code tasked with recovering. But if that state were made explicit as part of the state machine, it would be available.
Concurrent programming isn't easy. And threads are not a silver bullet; there is no such thing.
to post comments)