OSNews: http://www.osnews.com/story/20931/Windows_7_Gets_User_Mode_Scheduling Exploring the Future of Computing en-us Copyright 2001-2010, David Adams adam+nospam@osnews.com Sun, 14 Mar 2010 19:33:17 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com hmmm http://osnews.com/thread?347562 http://osnews.com/thread?347562 I am far from an expert at windows programming, but I thought the way it worked were processes were big, heavyweight things that contained multiple threads, as opposed to Unix which just had threads and would fork them. Sat, 07 Feb 2009 01:27:00 GMT donotreply@osnews.com (google_ninja) Comments RE: hmmm http://osnews.com/thread?347565 http://osnews.com/thread?347565
I am far from an expert at windows programming, but I thought the way it worked were processes were big, heavyweight things that contained multiple threads, as opposed to Unix which just had threads and would fork them.


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. Sat, 07 Feb 2009 02:54:00 GMT donotreply@osnews.com (galvanash) Comments RE[2]: hmmm http://osnews.com/thread?347572 http://osnews.com/thread?347572 That makes sense, but I figured that part of the overhead of windows processes had to do with scheduling. guess I was wrong

Thanks for the info ;) Sat, 07 Feb 2009 04:02:00 GMT donotreply@osnews.com (google_ninja) Comments Wait a sec... http://osnews.com/thread?347573 http://osnews.com/thread?347573 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 Sat, 07 Feb 2009 04:32:00 GMT donotreply@osnews.com (rexstuff) Comments So... http://osnews.com/thread?347574 http://osnews.com/thread?347574 ...in plain English, what does this mean? Faster Folding@Home performance from my Quad Core CPU in Windows 7?Edited 2009-02-07 04:35 UTC Sat, 07 Feb 2009 04:34:00 GMT donotreply@osnews.com (1c3d0g) Comments RE[2]: hmmm http://osnews.com/thread?347579 http://osnews.com/thread?347579 Actually you got M and N reversed ;) .

The kernel cares about N and the M is handle in user-mode. Sat, 07 Feb 2009 06:45:00 GMT donotreply@osnews.com (PlatformAgnostic) Comments RE: So... http://osnews.com/thread?347580 http://osnews.com/thread?347580 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. Sat, 07 Feb 2009 06:56:00 GMT donotreply@osnews.com (PlatformAgnostic) Comments "Playback Speed" in Silverlight ? http://osnews.com/thread?347582 http://osnews.com/thread?347582 I generally listen to MSDN videos by downloading the WMV so that I can spend 25 minutes instead of 50 minutes - Dave Probert being one of those slow-speaking types this would be ideal. But tonite the connection is slow, it would have taken two hours to download.
"Silverlight Configuration" did not seem to contain a "Play Speed" option, can this really be missing ? Sat, 07 Feb 2009 07:39:00 GMT donotreply@osnews.com (pg--az) Comments Been here all the time http://osnews.com/thread?347594 http://osnews.com/thread?347594 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 Sat, 07 Feb 2009 10:44:00 GMT donotreply@osnews.com (Invincible Cow) Comments RE: So... http://osnews.com/thread?347598 http://osnews.com/thread?347598 Unlikely, BOINC (seti@home, folding@home, etc) doesn't use threads for processing. (Multiple processes are used instead.)

- Gilboa Sat, 07 Feb 2009 11:12:00 GMT donotreply@osnews.com (gilboa) Comments FreeBSD and Solaris not using it http://osnews.com/thread?347616 http://osnews.com/thread?347616 FreeBSD and Solaris used to do M:N, but they switched to 1:1 (in Solaris 10 and FreeBSD 7) when they realized that their M:N couldnt match the Linux 1:1 ... Sat, 07 Feb 2009 14:44:00 GMT donotreply@osnews.com (diegocg) Comments RE: FreeBSD and Solaris not using it http://osnews.com/thread?347624 http://osnews.com/thread?347624
FreeBSD and Solaris used to do M:N, but they switched to 1:1 (in Solaris 10 and FreeBSD 7) when they realized that their M:N couldnt match the Linux 1:1 ...


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. Sat, 07 Feb 2009 15:56:00 GMT donotreply@osnews.com (kaiwai) Comments RE: Been here all the time http://osnews.com/thread?347630 http://osnews.com/thread?347630 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
: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 Sat, 07 Feb 2009 17:03:00 GMT donotreply@osnews.com (looncraz) Comments RE[2]: Been here all the time http://osnews.com/thread?347639 http://osnews.com/thread?347639 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. Sat, 07 Feb 2009 19:19:00 GMT donotreply@osnews.com (PlatformAgnostic) Comments RE[2]: FreeBSD and Solaris not using it http://osnews.com/thread?348277 http://osnews.com/thread?348277 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 Wed, 11 Feb 2009 15:53:00 GMT donotreply@osnews.com (Bill Shooter of Bul) Comments