LA.NET [EN]

Apr 02

In these last days I’ve been busy with the source code of the futures assembly. I’ve already written one post (not published yet) and was planning on writing a couple more of them that showed how to use the asynchronous features introduced by the future bits. Well, it seems like my posts have just become redundant (though I’ll probably publish them anyway) because there’s a new document on codeplex which explains how to use it.

13 comments so far

  1. Israel Aece
    11:16 am - 4-2-2009

    Hi Luis,

    Nice stuff. But, in a quickly read in this paper, I saw that AsyncController uses the ThreadPool. So, you can combine the controller with Wintellect CallbackThreadPool to use IO Threads.

    Att,

  2. luisabreu
    5:39 pm - 4-2-2009

    hum…not following…can you give more details on what you”re saying?

  3. Israel Aece
    6:52 pm - 4-2-2009

    Hi Luis,

    ASP.NET WebForms uses ThreadPool threads to serve requests. When we have a request that makes a heavy IO task (like databases, web services, etc.), it blocks this thread until finalize the task.

    So, the main benefit of the Async Pages (in WebForms), is that the async process will run in an IO thread, leaving ThreadPool to serve another requests.

    But, in a quickly read in this paper, I saw that AsyncController uses the ThreadPool, not an IO thread.

    Att,

  4. Levi
    7:36 pm - 4-3-2009

    All ASP.NET requests begin on a thread pulled from the ThreadPool. WebForms and MVC are not exceptional in this regard. Because of this, you should never call a blocking method from your code. If you do, then using async will actually hurt performance rather than help it because of the overhead involved with processing async requests.

    The trick is that you”re supposed to keep the logic that”s executing on this thread very short. From within your action method, kick off a request to an async operation that uses an I/O completion port for its work. Then the thread servicing the action method returns back to the ThreadPool very quickly, and it”s free to service another request.

  5. luisabreu
    8:33 pm - 4-3-2009

    Ah, the old IO/worker thread issues…Ok, I recall that IIS 6 introduced some changes to this and all ASP.NET requests are now handled by worker threads (instead of IO threads, like happened with IIS 5). If this is correct, then I”d go as far as saying that async actions will only be useful when you”re doing a long action which involves delegating to IO threads (ex.: web service calls, async database access – I”m under the impression that completion ports are used for async db access introduced by .NET 2.0 – etc.). what do you guys think? are there any benefits in doing any async work if IO is not involved?

  6. Levi
    9:55 pm - 4-3-2009

    We designed the AsyncController with the intent that action method authors would delegate work to components that internally used I/O completion ports, as you mentioned. There probably won”t be any benefit to using the AsyncController if all of your work is performed on ThreadPool threads, since you”ll be pegging the CPU anyway and IIRC you”ll be using the same ThreadPool that ASP.NET uses to respond to requests.

    Now, if you were a power user and really knew what you were doing, I suppose you could maintain your own ThreadPool (separate from ASP.NET”s and the CLR”s) and have your async methods delegate into *that*. In general I”d not recommend this, but if you were careful about what kind of work you posted to that ThreadPool then you could probably make some fairly strong performance guarantees. But I try not to play around too much in black magic territory. :)

  7. Israel Aece
    12:24 pm - 4-4-2009

    Hi Luis,

    I think that MVC uses the thread from the ThreadPool to process request and, in sample that exists in document of the Async Controller, it uses the ThreadPool again. IMHO, I believe that there are no benefits in this case. The main purpose of async pages of WebForm is to leave threads to process “light” request, where IO work isn”t involved.

    Maybe, you can combine AsyncController with Wintellect”s CallbackThreadPool to use IO Threads, like I showed here: http://weblogs.pontonetpt.com/israelaece/posts/28605.aspx, leaving thread to serve another request while you executes IO task.

    Best Regards.

  8. luisabreu
    1:20 pm - 4-4-2009

    Hello again Levi. Thanks for the feedback!

  9. luisabreu
    1:25 pm - 4-4-2009

    Hello Israel. To be honest, I”ve just given a quick glance at the async doc, so I”ll have to go back to it again and see the code that they”re showing.

    I”m still unsure on why you”d want to use IO threads for doing the work *if* it”s not IO related…btw, you can use PLINQ for making your sync actions async…god, only 30 secs looking at multithreading and my head is already hurting :)

  10. Israel Aece
    2:41 pm - 4-4-2009

    Hello Luis,

    You can use ADO.NET 2.0 async methods, or invoke WebServices via BeginXXX/EndXXX methods inside of async controller method. These operations already use IO thread to process.

    LINQ To SQL doesn”t support async execution so, envolve this execution via delegates, don”t provide any benefits.

    The problem is that the sample is using the ThreadPool, “stealing” threads from ThreadPool.

    Bye

  11. Levi
    6:19 pm - 4-4-2009

    Hi Israel –

    Code that spawns off a worker thread and calls Thread.Sleep() is fairly common in writing sample code for Async patterns, but you wouldn”t actually go off and do this in the real world. :) It”s just a sample showing that everything works; it”s not best practice. The other samples (the ones that use RegisterTask) are what you should be focusing on, as they don”t use the ThreadPool.

  12. luisabreu
    9:55 am - 4-5-2009

    Guys, thanks for the great discussion. Levi, I believe that Israel has a point: it would be probably a good idea to add a note saying that you shouldn”t be delegating work to the threading pool during an async action (I believe that an additional note to the doc would be all that is needed to warn people about it)

  13. luisabreu
    10:07 am - 4-5-2009

    btw, I thought I”d add this link to the discussion: http://blogs.msdn.com/ericeil/archive/2008/06/20/windows-i-o-threads-vs-managed-i-o-threads.aspx

    It seems like managed IO threads aren”t really equivalent to unmanaged IO threads. I think this discussion has just made me realize that I need to really start studying multithreading (which was one of my objectives to this year)

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>