Erika Parsons and Eric Eilebrecht : CLR 4 - Inside the Thread Pool

"But would it make sense that the CLR take use of the UMS on windows 7?"

Not so much.  Because if you can stay in managed code, you don't have to context switch into native - which saves a lot of time and work.  So keeping all locks, queues, and threads pools (as much as possible) in managed code is more or less more efficient.

Interesting. Thanks again.

I think it will turn out that we don't need more threading abstractions, but less.  In fact we need as close to zero as we can get.  In most code, it turns out that blocking on IO is the major need to spin up new threads so you can wait on 1 thing and continue to do something else.  If you can remove blocking, or at least make it appear to be gone, you can remove a lot of this.  Take for example and common server app.  You block waiting for a connection, then get the request, then block on some other IO during processing, then send a reply.  During this cycle, your doing a lot of thread management to keep stuff lively and also not making a thread per request.  However a thread per request is exactly how you really want to program because its easier.

This may be a language issue, but why can blocking and callbacks and delegates/lambdas be further abstracted away?  Take a simple read socket, write to disk, and write ok back to client:

byte[] request = mysock.Read();
file.Write(request);
mysock.Write("OK");

So in todays world, we block on read, block on file write and block on socket write.  So we normally can't write it this way because we are tying up a thread for each client request.  So we fall back to async IO, which adds tons of complication and mess.  Now tools such as TPL and CCR try to address this and make it easier, but the model is still overly complex.  We need a new model.  Why can't the Read above, fire off the request and transparently (to me) return the now blocking thread to do other work for others and come back with result when the request is done (kinda coroutineish) - maybe the returning thread is different, we should not need to know or care?  Same with other methods above.  So everything is actually async, but looks and feels sync.  No callback blocks or other such goo.  The runtime handles this in the background.  It does require that all thread depency code needs to be removed or abstracted for us in the language and BCL.  Programmer should not have to think about that anyway and should be abstracted.  Couldn't this work?