Re: Userland threading and messaging

[Chip Norkus <wd@xxxxxxxx>]

On Saturday 16 August 2003 04:05 am, Joerg Sonnenberger wrote:
> On Sat, Aug 16, 2003 at 03:30:57AM -0500, Chip Norkus wrote:
> [snip]
>
> > 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).

> Joerg
>

-wd
-- 
chip norkus; renaissance hacker;                wd@xxxxxxxx
"question = (to) ? be : !be;" --Shakespeare     http://telekinesis.org/