locked
Difference between Multithreading and Asynchronous programming

    Question

  • Hi,

    Please answer my question:

    "What is the difference between Multithreading and Asynchronous progamming?"

    I have read many articles but couldn't get correct explanations.

     

    Thanks and Regards,

    ChatanyA Agrawal

    Tuesday, March 14, 2006 4:13 PM

Answers

  • Multithreading is different parts of a program running, typcially called threads.

    Asynchronous programming uses threads to kick off a piece of code.   So asynchronous programming relies on multithreading to work.

    Let's say you have a program that needs to get the latest stock information.  To do so it has to query a web service.  If you make this request "synchronously", it will use the same thread the program is running in.  This causes the program to have to wait for that task to complete before it can go onto the next task.  This means the user cannot click on the UI or do anything, they have to wait on the current thread to release.

    Instead, you would want to make the call to the web service to check on the stock asynchronously. It doesn't matter if it takes the web service 1 second or 2 minutes to complete the calculation.  This call asynchronously is running on another thread though. 

    Now the programming aspect of this is that when the web service reports back that it is done you are alerted in code by an event handler that it is complete, and then you can finish doing whatever you want in code when it finishes.    All the while this asynchornous call is going on, the main program is running on another thread and is still carrying out tasks as normal allowing the user to click around and keep the UI responsive.

    To sum it it I would say:

    Asynchronous programming is more of a programming technique on how to use multithreading in an application.

    Hope that helps.

    -The Elder

    Tuesday, March 14, 2006 5:38 PM
  • There's not a real big difference, except to say that multithreading apps spread out their work effectively across, multiple-threads... These threads are said to be running Asyncronously. The benefit this has in terms of performance is that a dual core cpu or dual proccessor pc will only benefit from apps whos tasks are spread out in some meaningful way across multiple threads.

    Note, multi-tasking refers to an older method of processes receiving fixed time-slices instead of true multithreading, where threads can have priorities etc...

    A common usage of asynchronous calls would be windows forms applications which need to call some sort of blocking code that retreives a resource like a web page, or a database connection, etc.

    Putting the code in its own thread prevents the gui from becomming unresponsive and is one of the most imporant reasons for using multiple threads when programming windows forms.

    You can see how many threads any particular task uses by using the taskmanager in windows (view -> select columns to add threads), you'll notice that your apps in .net typically use multiple threads for various things without your explicitly having told it to do so--- but your blocking code, or code that could benefit from being run asyncronously should be explicity coded to do so.

    In 2.0, .net introduced the BackgroundWorker class, which provides a pretty simple way of creating threads and getting progress reports from them or callback data after they complete... The class doesn't have all the same flexibility as the older threading classes, but it's generally simpler to create and manage, still, with some extensions to the BackgroundWorker class, you can add features (like immediate cancellation), that aren't there--- but I think are usefull.

    Before 2.0 people used AsyncCallback to manually do similar things encapuslated in the BackgroundWorker class--- I'm sure some people may prefer this control over threading,

    You can also do asyncronous anonymous delegates, which is a pretty painless way to create a method-less block of code that runs in it's own thread.

    Tuesday, March 14, 2006 8:45 PM

All replies

  • Multithreading is different parts of a program running, typcially called threads.

    Asynchronous programming uses threads to kick off a piece of code.   So asynchronous programming relies on multithreading to work.

    Let's say you have a program that needs to get the latest stock information.  To do so it has to query a web service.  If you make this request "synchronously", it will use the same thread the program is running in.  This causes the program to have to wait for that task to complete before it can go onto the next task.  This means the user cannot click on the UI or do anything, they have to wait on the current thread to release.

    Instead, you would want to make the call to the web service to check on the stock asynchronously. It doesn't matter if it takes the web service 1 second or 2 minutes to complete the calculation.  This call asynchronously is running on another thread though. 

    Now the programming aspect of this is that when the web service reports back that it is done you are alerted in code by an event handler that it is complete, and then you can finish doing whatever you want in code when it finishes.    All the while this asynchornous call is going on, the main program is running on another thread and is still carrying out tasks as normal allowing the user to click around and keep the UI responsive.

    To sum it it I would say:

    Asynchronous programming is more of a programming technique on how to use multithreading in an application.

    Hope that helps.

    -The Elder

    Tuesday, March 14, 2006 5:38 PM
  • To add,

    Once you can effectively use events, delegates and asynchronous delegates, you will be able to enforce looser coupling which will add alot of maintainability and extensibility in your OOP programs.

    Tuesday, March 14, 2006 7:56 PM
  • There's not a real big difference, except to say that multithreading apps spread out their work effectively across, multiple-threads... These threads are said to be running Asyncronously. The benefit this has in terms of performance is that a dual core cpu or dual proccessor pc will only benefit from apps whos tasks are spread out in some meaningful way across multiple threads.

    Note, multi-tasking refers to an older method of processes receiving fixed time-slices instead of true multithreading, where threads can have priorities etc...

    A common usage of asynchronous calls would be windows forms applications which need to call some sort of blocking code that retreives a resource like a web page, or a database connection, etc.

    Putting the code in its own thread prevents the gui from becomming unresponsive and is one of the most imporant reasons for using multiple threads when programming windows forms.

    You can see how many threads any particular task uses by using the taskmanager in windows (view -> select columns to add threads), you'll notice that your apps in .net typically use multiple threads for various things without your explicitly having told it to do so--- but your blocking code, or code that could benefit from being run asyncronously should be explicity coded to do so.

    In 2.0, .net introduced the BackgroundWorker class, which provides a pretty simple way of creating threads and getting progress reports from them or callback data after they complete... The class doesn't have all the same flexibility as the older threading classes, but it's generally simpler to create and manage, still, with some extensions to the BackgroundWorker class, you can add features (like immediate cancellation), that aren't there--- but I think are usefull.

    Before 2.0 people used AsyncCallback to manually do similar things encapuslated in the BackgroundWorker class--- I'm sure some people may prefer this control over threading,

    You can also do asyncronous anonymous delegates, which is a pretty painless way to create a method-less block of code that runs in it's own thread.

    Tuesday, March 14, 2006 8:45 PM
  •  

       Thanks all og you guys for your quick response:

    I want to tell my understanding in one line:

    1) Asynchronous programming use multithreading and it callback the function once it finish the task.

    2) Without multithreading, Asynchronous programming can't achieved.

    3) Question is:"What are the other way to use multithreading beside asynchronous programmin?"

    Guys please let me know your views on this.

    Thanks and Regards,

    ChatanyA Agrawal

    Thursday, March 16, 2006 6:56 AM
  • Whereas responsive forms applications (that do anything at least) usually must make use of seperate 'worker' threads in order to prevent blocking the UI, for performance across app domains, the OS manages the threads of each application giving some priority over others---- which is why say, when there is a particularly nasty problem with one application it can adversely affect the responsiveness of the other applications running on the host OS.

    Make sense?

    Friday, March 17, 2006 10:14 PM
  • Hi,

    Asynchronous programming does not imply multithreading, though they look the same. The difference between the 2 is explained in this article.

    Also, you should take a look at this post.


    Sincerely, Brecht



    • Edited by BrechtVsk Tuesday, October 09, 2012 2:12 PM
    Tuesday, October 09, 2012 2:07 PM