Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

jods

jods jods

Niner since 2009

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

    @Charles: I've read a bit about Axum, but didn't check it in depth yet. Indeed I think we'll probably have to introduce new concepts into the languages to be able to safely and easily code multithreaded applications.

    @staceyw: indeed threads are an important resource, if you block 1000s of them you need a better way to handle concurrency. You are totally correct: currently the solution is asynchronous programming and current languages make it unnecessarily hard.

    Did you check the F# asynchronous features? It's very similar to the idea you described. Basically you write your code inside an async {} block, and you can write everything just like the usual synchronous code (with the exception of adding an exclamation mark (!) before asynchronous calls). The language takes care of all the details. It's a very nice feature.

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

    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)

    Isn't it what it actually does? When a thread blocks on an I/O, its CPU time slice is preempted by the OS scheduler and another thread immediately gets to run. It's exactly the behavior you described, except the thread object isn't reused for other work (which is hard because a thread has a lot of context... the stack to start with), but another thread can run. So no CPU time is "lost".

    The point is that this situation doesn't create parallelism. If your application wasn't written with some multithreading in mind, it may well have no work to do during the blocking call. This is something a compiler can't invent, you have to express your parallelism or "tasks" to some degree. For example most app today are written in a purely single threaded way, so even if the scheduler wanted to re-use your thread during the blocking call, what task would it use for?

    Another point is that the thread is actually *blocked*. Even if you have more work going on other threads, this may be bad... E.g. if this is your UI thread.

    Overall I think that the Tasks concept is a good move. It's a bit like LINQ: don't say how to do something, describe the result you want and let the "black box" operate. The applications I am working on could easily benefit from throwing tasks at the runtime on multicore machines.

    Of course, the hard problem which remains to be solved is how to handle concurrency when there is shared state (and there always is some). Correctness and performance are hard and I would love to see some simplifications in that area (the concurent collections and other primitives in .NET 4 being a good start, but I have the feeling this is not enough to ensure easy and safe multithreaded development).