Grant Edwards wrote:
The advantage is that you can structure a protothread as "normal" thread with linear code that waits in multple places. With a simple run() function, you've got to explicitly design and implement a state machine. With protothreads, the state machine is implicit in the ordering and control flow of the source code. I find normal C control flow mechanisms (if-then-else, while, switch, etc.) far, far, easier to read and maintain that an explicit state-machine with a giant switch() statement and assignments to state variables that are in effect just gotos that allow you to create completely indecipherable paths through the state machine.
Working with this type of state machines is very much like programming in assembly language: there are no flow control mechanisms to assist the programmer. Sure, it is possible to write nice code that way but it pretty much require you to be a wizard to do it. And after a few years you sort of get tired of being that wizard :) Particularly if you for some reason need to go through your own old code...
To evaluate the usefulness of protothreads, I rewrote a bunch of state machine-based programs with protothreads (see the protothreads paper from SenSys 2006). When rewriting them, I found a couple of state machine-related bugs that had been in the code - undetected - for years. They were corner cases and very difficult to spot by just looking at the state machine code. With protothreads, the flow control is implicit and visible so spotting errors in the flow control logic is much, much easier.
/adam -- Adam Dunkels <[email protected]> http://www.sics.se/~adam/
