I was reading about how Solaris 2 implements multithreading by using user threads, lightweight processes, and kernel threads. Since the kernel is only responsible for scheduling kernel threads, the thread library that runs in user mode has to schedule user threads onto the LWPs. I'm wondering how the thread library is able to schedule the threads. Is it scheduled cooperatively or preemptively? If they are scheduled cooperatively, how is it possible to prevent threads from hogging an LWP? If they are scheduled preemptively, how is the library supposed to get timer IRQs if the kernel has control over the interrupts?
Confused...
User level thread scheduling
User level thread scheduling
Last edited by deadmutex on Tue Dec 20, 2005 12:00 am, edited 1 time in total.
-
Da_Maestro
- Member
- Posts: 144
- Joined: Tue Oct 26, 2004 11:00 pm
- Location: Australia
Re: User level thread scheduling
They are scheduled co-operatively. To schedule the threads, the library only needs to hook the "alarm" signal up to a function that changes the context of the currently executing thread.
I guess the library would use a round-robin scheduler, as it doesn't have the privelages to perform any kind of process blocking or whatnot.
I guess the library would use a round-robin scheduler, as it doesn't have the privelages to perform any kind of process blocking or whatnot.
Two things are infinite: The universe and human stupidity. But I'm not quite sure about the universe.
--- Albert Einstein
--- Albert Einstein
Re: User level thread scheduling
Multiple userland threads mapped to 1 kernel thread was dropped in Solaris 8 for standard 1-1 (kernel-user) threads because the M-N produced unusual behaviour and normal 1-1 threads perform much better.
You can preload the normal 1-1 library in Solaris 8 by using a supplied library that came with it.
export LD_PRELOAD=/lib/lwp/libthread.so
Before they realised that M(ultiple) userland threads mapped to a few (N) kernel threads actually gave worse performance, they went full ahead declaring M-N as the better way to do things. Then they realised that it sucked and you won't find it any more after Solaris 8.
I've personally experienced problems with M-N mapping when threads started acting funny in large applications doing intensive tasks. It took me a whole day of research until one of my colleagues told me how he spent a week debugging an issue with the userland threads in an application which worked normally on other platforms.
Not only that but userland threads require inserting signal/alarms/cooperative multitasking hooks throughout your userland libraries or scheduling alarms (which requires kernel intervention anyway)... it's a lot of work for something that is easily done in the kernel.
You could possibly debate the benefits of userland scheduling in theoretical or staged situations beacuse a lot of things work in theory.
You can preload the normal 1-1 library in Solaris 8 by using a supplied library that came with it.
export LD_PRELOAD=/lib/lwp/libthread.so
Before they realised that M(ultiple) userland threads mapped to a few (N) kernel threads actually gave worse performance, they went full ahead declaring M-N as the better way to do things. Then they realised that it sucked and you won't find it any more after Solaris 8.
I've personally experienced problems with M-N mapping when threads started acting funny in large applications doing intensive tasks. It took me a whole day of research until one of my colleagues told me how he spent a week debugging an issue with the userland threads in an application which worked normally on other platforms.
Not only that but userland threads require inserting signal/alarms/cooperative multitasking hooks throughout your userland libraries or scheduling alarms (which requires kernel intervention anyway)... it's a lot of work for something that is easily done in the kernel.
You could possibly debate the benefits of userland scheduling in theoretical or staged situations beacuse a lot of things work in theory.