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.
Thread beginning with comment 344187
To read all comments associated with this story, please click here.
by madhatter on Sun 18th Jan 2009 13:24 UTC
Member since:

I don't have much experience in thread-programming and none in protothreads, and the Wikipedia page wasn't very helpful.
For less memory overhead you probably have some disadvantage, so can anybody tell me what the tradeoff here is?

Reply Score: 2

RE: Drawbacks?
by TechStorm on Sun 18th Jan 2009 14:54 in reply to "Drawbacks?"
TechStorm 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

RE: Drawbacks?
by ValiantSoul on Sun 18th Jan 2009 15:36 in reply to "Drawbacks?"
ValiantSoul Member since:

These are application level (user-space) threads, as opposed to kernel level threads, so yes there are disadvantages.

Using your own scheduler means ALL of your threads are at the mercy of the kernel scheduler as if they were only 1 thread. This means that if the scheduler worked by evenly dividing time without priorities, and if it didn't context switch on I/O, and you had 4 threads with 8 kernel threads (1 of which being yours), your application would get 1/8 (12.5%) of the CPU time. With kernel level threads you would have 5/12 (41.6%) of the CPU. Of course the kernel scheduler doesn't actually work that way though...

That supposed 400x performance increase that is referenced on the WIKI is most likely something that wouldn't be processor intensive, it was probably just spawning off a bunch of threads. Spawning kernel threads can be expensive (especially if your goal is just to spawn a bunch of them and not really do anything else)

Other disadvantage is they can't use multiple cores/processors -- you are stuck with just the one you started on.

Now, in an embedded system these may not be a big issue. For performance, you probably don't have many other threads running, and yours should get the priority if setup properly. And unless you are using some sort of embedded cell, you probably only have 1 processor 1 core. If you do have 2 cores though, this could work well if your thread is running on a different core than the rest of your threads.

Reply Parent Score: 3

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

Why would any scheduler that makes an attempt at fairness across processes do that? In a multiprogramming context, if a process had a higher weight according to the number of threads it had, you'd violate performance isolation among processes by being able to cheat the system into giving you a higher priority by just spawning off more threads. The most obvious solution is to allocate a time slice per process and multiplex that timeslice between its threads.

You can easily utilize multiple cores and processes so long as you have some abstraction for an execution context (i.e. kernel threads). Simply have a kernel thread for each cpu, dispatch user threads to each kernel thread, and you're good to go (this is known as n:m threading).

User-level threading's disadvantage lies in the fact that a thread may block on a system call while there are more user threads on the host kernel thread that can be executed. Along similar lines, the kernel may try to infer workload properties based the thread's behavior. With user-level threads, you're going to end up with the least common denominator (e.g interactive user-thread being masked by a cpu intensive user-thread). Essentially this is an area where the end-to-end principle isn't being applied. Some solutions have been proposed but have ultimately been rejected as being too slow, too intrusive, or too difficult to implement and maintain.

Reply Parent Score: 1