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 344275
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Drawbacks?
by helpfulhelper on Sun 18th Jan 2009 23:27 UTC 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