Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C#
  4. asynchronous calls & threading. which is better?

asynchronous calls & threading. which is better?

Scheduled Pinned Locked Moved C#
csharpsysadminperformancequestionlearning
12 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Li kai Liu Angus

    Hi, I've seen a few Server/Client programs here. Many of the server programs that can handle many connections at the same use asynchronous calls. I just can't figure out why this approach is popular in C#. Why most people use it instead of threads? Any advantages? If I want to write a ftp server that can take control of each connection(e.g. D/L speed control, kill connection on user's demand), are asynchronous calls recommended in this case? Is the underlying mechanism of asychronous calls also use threading things? Thanks in advance:) A beginner

    N Offline
    N Offline
    Nish Nishant
    wrote on last edited by
    #2

    When there are too many connections, there are too many threads and if each connection requires moderate to heavy processing, you'll bring the machine down in no time Nish


    Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

    1 Reply Last reply
    0
    • L Li kai Liu Angus

      Hi, I've seen a few Server/Client programs here. Many of the server programs that can handle many connections at the same use asynchronous calls. I just can't figure out why this approach is popular in C#. Why most people use it instead of threads? Any advantages? If I want to write a ftp server that can take control of each connection(e.g. D/L speed control, kill connection on user's demand), are asynchronous calls recommended in this case? Is the underlying mechanism of asychronous calls also use threading things? Thanks in advance:) A beginner

      E Offline
      E Offline
      Eric Gunnerson msft
      wrote on last edited by
      #3

      The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. That means you can be waiting for 100 different read operations to finish using completion ports without a lot of overhead, where if you used threads, you'd need to have 100 of them running at the same time, and that takes a lot more resources.

      N J 2 Replies Last reply
      0
      • N Nish Nishant

        Eric Gunnerson (msft) wrote: In .NET, the built-in async functions use this support. Wow! That's cool info Eric Gunnerson. Thanks for that. It amazes me also to see you spot just the right threads here on CP. Thanks, once again, Nish


        Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

        E Offline
        E Offline
        Eric Gunnerson msft
        wrote on last edited by
        #4

        Sometimes I get lucky...

        L 1 Reply Last reply
        0
        • E Eric Gunnerson msft

          The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. That means you can be waiting for 100 different read operations to finish using completion ports without a lot of overhead, where if you used threads, you'd need to have 100 of them running at the same time, and that takes a lot more resources.

          N Offline
          N Offline
          Nish Nishant
          wrote on last edited by
          #5

          Eric Gunnerson (msft) wrote: In .NET, the built-in async functions use this support. Wow! That's cool info Eric Gunnerson. Thanks for that. It amazes me also to see you spot just the right threads here on CP. Thanks, once again, Nish


          Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

          E 1 Reply Last reply
          0
          • E Eric Gunnerson msft

            Sometimes I get lucky...

            L Offline
            L Offline
            Li kai Liu Angus
            wrote on last edited by
            #6

            Thank you:) but when to use threads? I mean what situations are better for creating threads, or in what cases, using asynchronous calls would be better? Now, I see that creating threads is more costly than using asynchronous calls. It seems that I cannot control the number of "threads" using asynchronous call. Then, if I'm writing a ftp server that only take 5 connections in maximum, it looks useless to me, is it?

            N E 3 Replies Last reply
            0
            • L Li kai Liu Angus

              Thank you:) but when to use threads? I mean what situations are better for creating threads, or in what cases, using asynchronous calls would be better? Now, I see that creating threads is more costly than using asynchronous calls. It seems that I cannot control the number of "threads" using asynchronous call. Then, if I'm writing a ftp server that only take 5 connections in maximum, it looks useless to me, is it?

              N Offline
              N Offline
              Not Active
              wrote on last edited by
              #7

              One reason to use async over threads would be in the case of file transfers. You would need to have the thread spinning and polling for completion. With an async call you would be notified when the operation completed. I would say a thread would be better used for a things like background operations, like refreshing a directory listing. It can be launched while the use is doing something else without interfering.

              1 Reply Last reply
              0
              • E Eric Gunnerson msft

                The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. That means you can be waiting for 100 different read operations to finish using completion ports without a lot of overhead, where if you used threads, you'd need to have 100 of them running at the same time, and that takes a lot more resources.

                J Offline
                J Offline
                James T Johnson
                wrote on last edited by
                #8

                Eric Gunnerson (msft) wrote: The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. What happens on 98/ME (*shudder*)? James Simplicity Rules!

                E 1 Reply Last reply
                0
                • L Li kai Liu Angus

                  Thank you:) but when to use threads? I mean what situations are better for creating threads, or in what cases, using asynchronous calls would be better? Now, I see that creating threads is more costly than using asynchronous calls. It seems that I cannot control the number of "threads" using asynchronous call. Then, if I'm writing a ftp server that only take 5 connections in maximum, it looks useless to me, is it?

                  E Offline
                  E Offline
                  Eric Gunnerson msft
                  wrote on last edited by
                  #9

                  If there's built-in support using completion ports (ie there are BeginXXX() and EndXXX() calls on the class), I think that's always the preferred choice, since it doesn't take any threads at all. It is true that for small numbers of concurrent processes, it can be a lot easier to write them as separate threads, because you can write the code all at once as part of a method, while with the async case, you may have to write your code in several chunks as part of the callback routines.

                  1 Reply Last reply
                  0
                  • J James T Johnson

                    Eric Gunnerson (msft) wrote: The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. What happens on 98/ME (*shudder*)? James Simplicity Rules!

                    E Offline
                    E Offline
                    Eric Gunnerson msft
                    wrote on last edited by
                    #10

                    On the 98 series, the runtime emulates the feature using threads.

                    J 1 Reply Last reply
                    0
                    • L Li kai Liu Angus

                      Thank you:) but when to use threads? I mean what situations are better for creating threads, or in what cases, using asynchronous calls would be better? Now, I see that creating threads is more costly than using asynchronous calls. It seems that I cannot control the number of "threads" using asynchronous call. Then, if I'm writing a ftp server that only take 5 connections in maximum, it looks useless to me, is it?

                      E Offline
                      E Offline
                      Eric Gunnerson msft
                      wrote on last edited by
                      #11

                      If there's built-in support for async (ie the class has BeginXXX() and EndXXX() methods), then you would normally use that if you care about scaling. If you're writing something small, then writing the threaded version is generally easier, because you write your code in one chunk rather than having to write several callback functions.

                      1 Reply Last reply
                      0
                      • E Eric Gunnerson msft

                        On the 98 series, the runtime emulates the feature using threads.

                        J Offline
                        J Offline
                        James T Johnson
                        wrote on last edited by
                        #12

                        Thanks Eric :) James Simplicity Rules!

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • World
                        • Users
                        • Groups