Linked by Thom Holwerda on Sat 7th Feb 2009 00:35 UTC, submitted by PlatformAgnostic
Windows M:N threading, in which a single kernel thread is multiplexed to run multiple logical user mode threads, has long been a feature of some Unix systems (Solaris and FreeBSD have had it for years). Even Windows NT has had "Fibers" for several releases, though they suffered from the same problems as other M:N schemes and were incompatible with many Win32 APIs. Join Windows Kernel Architect Dave Probert for a discussion on the new User Mode Scheduling Feature which solves these problems while allowing applications fine grained control over their threads.
Thread beginning with comment 347594
To read all comments associated with this story, please click here.
Been here all the time
by Invincible Cow on Sat 7th Feb 2009 10:44 UTC
Invincible Cow
Member since:

Since these threads are user-mode threads (of course mapped onto one or more kernel threads) they can be managed from user-mode (i.e. your own program). Kernel mode or special API support is not needed. Anyone who would have wanted this could have written M:N threading for their own application already.

Edited 2009-02-07 10:44 UTC

Reply Score: 2

RE: Been here all the time
by looncraz on Sat 7th Feb 2009 17:03 in reply to "Been here all the time"
looncraz Member since:

Yup - at least I did :-)

My setup is simple, but VERY effective:


A Thread Manager doing the job of the kernel:

class ThreadManager<class ThreadPolicy = MNRoundRobin>
:public Manager, protected ThreadingObject

And a Thread class:

class Thread;

Yup, that is all it takes to do it!

Each Thread can can itself be split onto any number of system threads, or it can share a system thread with other threads. The ThreadManager owns ALL threads.

I also created another type of object type to simplify async function calls: AsyncExec. In this way any object wishing to provide asynchronous calls or to issue async callbacks can do so rather easily ( though I am still trying to find ways to reduce required code mass for this - duplicating every function call certainly ain't a great way - even if it is automated through a build tool... ).

Oh well, once again Microsoft does what everyone else is doing, does it worse, and calls it innovation! Heck, they probably patented it as well, which will be fun considering my code has been done for.. well.. a long time ;-)

--The loon

Reply Parent Score: 2

PlatformAgnostic Member since:

What do you do when one of your kernel threads blocks, either to wait on some synchronous I/O or on a pagefault, over which you have no control? If you could somehow know that you need to start running a new thread (there's a way to do this on Windows via IO Completion Ports), how do you ensure that the two threads which are now active are not thrashing in competition for CPU time.

You can't implement this without kernel support.

Reply Parent Score: 2