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.
Post a Comment
Member since:
2006-02-05
Member since:2006-01-25
In windows processes are heavy and kernel threads are much lighter. In Linux processes are much, much lighter than in Windows - kernel threads are lighter still but the difference isn't as extreme. Essentially it boils down to Linux process management structures being very heavily performance optimized (mostly because threads were not attractive to most Linux programmers early on so a whole lot of work went into make fork() cheap)
So processes in Linux tend to be cheap enough that using kernel threads is often not worth the complexity it adds and parallel programming is often done just using simple fork() calls. On windows forking processes to achieve parallel execution is MUCH slower than using threads - so much so that is is seldom done outside of special case scenarios.
M:N threading is yet another layer of abstraction where essentially the OS only knows or cares about scheduling the M side - the N side is scheduled using a userland library. The M side can be a process or a thread depending upon how the library is implemented.
Member since:2006-02-05
Member since:2006-01-02
Member since:
2007-04-06
Doesn't an M:N model imply that a number of user space threads can be mapped onto not just one, but a number of kernel space threads?
That seems to be what wikipedia has to say...
http://en.wikipedia.org/wiki/Thread_(computer_science)#N:M
Edited 2009-02-07 04:34 UTC
Member since:
2005-07-06
Member since:2006-01-02
It depends on how folding@home processes items. If it has a set of threads that rarely interact but keep chugging away at their own immutable portion of the problem, then this won't help (the program should just create 4 threads and run, run run!). If folding@home has to coordinate who can process which data, or if some threads create data for other threads to consume, then this should make that operate faster.
Member since:2005-07-06
Member since:
2006-06-24
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
Member since:2005-07-24
Yup - at least I did :-)
My setup is simple, but VERY effective:
psuedo-code:
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
Member since:2006-01-02
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.
Member since:
2005-07-08
Member since:2005-07-06
True, but not for those reasons. IN theory M:N should be superior to 1:1 but to get the performance required the complexity is so high that in the end one has to argue whether it pays off in the end. Linux was almost going to get M:N in the form of NGPT (Next Generation POSIX Library) that was under development by IBM, but was instead superseded by NPTL.
The only operating system that I know of which has really good M:N threading performance was Tru64 - but the complexity of achieving the same performance in Solaris and Linux just doesn't pay off in the end.
Its one of those 'in theory' arguments when it comes to engineering. In Theory M:N should be superior, in theory the Itanium should the performance king - but when the rubber hits the road and all the ugly code, are thrown at it, all the synthetic benchmarks in the world aren't going to change it from being a 'nice in theory' idea.
Member since:2006-07-14
Do you have to really program specifically for M:N, or does the operating system just take your thread creation requests and treat them as these fibers? I would think that M:N would only make sense if the application were creating a large number of threads in multiple programs. Otherwise there are two levels of scheduling overhead. If the server is single purposed, it should only have one of those. Of course on desktops and servers that have a more varied load, it might make some sense.
Edited 2009-02-11 16:06 UTC
