Linked by Thom Holwerda on Sun 18th Jan 2009 11:16 UTC, submitted by anonymous
General Unix Protothreads are a type of extremely lightweight threads - each protothread requires only two bytes of memory - that are usually used for embedded firmware programming, where memory is at a premium. Protothreads combine the low overhead with event-driven programming with the algorithmic clarity of threaded programming.
E-mail Print r 5   · Read More · 16 Comment(s)
Thread beginning with comment 344198
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Drawbacks?
by TechStorm on Sun 18th Jan 2009 14:54 UTC in reply to "Drawbacks?"
Member since:

Normal threads store function variables in their own stack, where they are preserved by the kernel. With the way protothreads work, context switching is simply marking where you were in the function and then returning all the way to the scheduler. The scheduler then resumes the next thread by a combination of function calls and goto statements. This is all hidden by way of macros. However, in the process, the values of the local function variables are lost. In order to retain the values of the variables, you need to have a pointer to a block of state data that needs to be passed as an argument to all functions that make use of the protothreads API. From the article given:

static pt_t producer_thr(void *const env) {
pc_thread_context_t *const c = env;

/* Do stuff */
*c->mailbox = c->i;

return PT_DONE;

given that

typedef struct {
pt_thread_t pt_thread; /* Required by protothreads */
pt_func_t pt_func; /* Required by protothreads */
int i; /* Function variable */
int *mailbox; /* Function variable */
} pc_thread_context_t;

where normally you would have used:

<return-type> producer_thr() {
int i;
int *mailbox;

/* Do stuff */
*mailbox = i;

This requires some more effort on part of the programmer. Note that recursion is non-trivial, because data goes to a data structure rather than the stack. Also, it should be noted that the protothreads API is heavily dependant on macros, goto statements, and gcc label variables (non-standard C). Protothreads are useful in systems whose kernel/OS do not support "normal" threads.

If a language can be extended such that the protothread API is part of the language itself, then I believe that the benefit of protothreads can be obtained without requiring the user to take any extra considerations (when compared to normal threads).

Also, the article makes some claims about performance. It should be noted that context switching for protothreads is dependent on the depth of nested function calls, but this is not a factor for the context switching of "normal" threads. Thus, it seems to me that comparing the performance of the two types of threading is a little like comparing apples and oranges, since threads that incur in very deep function calls will at some point be slower than regular threads.

Nevertheless, a cool invention and a nice implementation right there.

Reply Parent Score: 8

RE[2]: Drawbacks?
by Vanders on Sun 18th Jan 2009 23:42 in reply to "RE: Drawbacks?"
Vanders Member since:

Seems like a rather long way around to do something you can already do with SySV ucontext manipulation. This appears to be a bit of a case of a solution in search of a problem, sadly.

Reply Parent Score: 2