Userland threading and messaging
wd at arpa.com
Sat Aug 16 02:30:02 PDT 2003
On Saturday 16 August 2003 04:05 am, Joerg Sonnenberger wrote:
> On Sat, Aug 16, 2003 at 03:30:57AM -0500, Chip Norkus wrote:
> > What about thread-to-processor binding? For compute-bound programs
> > it is very nice to be able to explicitly stick threads onto different
> > CPUs. For that there would need to be some kind of kernel code at
> > least.
> Right. Not only compute-bound programs, but things like webservers
> have there use for sticking too. That's what I meant with the virtual
> CPUs. The process asks the kernel to provide e.g. 4 virtual CPUs.
> In fact this are just some more LWPs. Now we have the userland
> scheduler utilizing these virtual CPUs like it knows best. Consider
> the webserver having 4 socket handling threads and 4 processing
> threads. It wants one handling and one processing thread per virtual
> CPU to simplify locking. The second part is the kernel scheduling the
> virtual CPUs to the different physical CPUs. That the place to add
> static VCPU-CPU mapping.
Ahhh, okay. This sounds good. I assume the user space scheduler can
request extra LWPs and release them as it needs?
> As a side note, this should be implementable even by a junior hacker
> like me since it is considerably simpler than e.g. KSE.
Well, the tricky part I imagine will be signal delivery. The threading
library will need to trap all available signals and then deliver them to
the appropriate thread. I don't know how easy (or hard) that will be.
Other than that it does seem relatively simple, provided the messaging
API provides a way for the library to attach extra data to messages, and
cancel pending requests when a thread goes away (or wait for those
requests to finish).
chip norkus; renaissance hacker; wd at xxxxxxxx
"question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/
More information about the Kernel