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 344209
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Drawbacks?
by ValiantSoul on Sun 18th Jan 2009 15:36 UTC in reply to "Drawbacks?"
ValiantSoul
Member since:
2005-07-20

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:
2009-01-18

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