On 2009-03-17, Jamie Lokier <[email protected]> wrote: > Michael Schnell wrote: > >> So I don't understand why you bother about "real" threads at >> all. some 50 Lines of C code will "schedule" your "threads" >> one after the other as part of a single application/process, >> all running on the same stack, > > That's fine if the code is simple enough to be event driven > and always returns to your event scheduler.
Exaclty. If your thread is a large loop that "completes" (blocks) at various places within that loop depending on state information it's much simpler and easy to maintain it as a loop that convert it into a state-machine with a single entry and a single exit each time it's scheduled. There are some clever macros (e.g. protothreads: http://www.sics.se/~adam/pt/) that allow you to write what appears to be a normal thread "loop" but is actually a single entry/exit FSM. I'm actually quite fond of protothreads and have used in applications that needed "threads" but couldn't use any interrupts. > But some code looks like spaghetti that way, and then it's > better to use scheduling points inside functions, rather than > having to return from the whole function stack after recording > local state into a state structure. Well said. > Of course you can still do that without a kernel :-) Yes, you can. But if the non-real-time part of the product requirement is to run a large web/network based application, then you just can't do without a kernel. > For more complex real-time stuff, often you have priorities, > locking between threads, and priority inheritance to avoid > priority inversion. The simple event-driven loop gets > complicated with priorities, when one event handler needs to > interrupt another event handler in the middle. The loop > starts to resemble a full blown kernel scheduler... Except that it rarely works right... -- Grant Edwards grante Yow! I know things about at TROY DONAHUE that can't visi.com even be PRINTED!! _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
