Disadvantages of using calling methods asynchronously using C#

[GVN]

Hi All,

Can anyone guide me when asynchronous method calls will be
benificial? Are there any

disadvantages of using asynchronous calls?


Thanks,

GVN

 

[Guest]

GVN,
Let's make it simple: Say you have an app that needs to get rss feeds from
1000 sites once every hour. You can serialize it by having one thread go
through all 1000 requests one at a time, or you can do it asynchronously on a
threadpool with say 30 threads, in which case you will have 30 requests going
simultaneously and as soon as a thread has finished it will pick up a new
request. This may not turn out to be exactly 30 times faster than the first
case, but I think you get the idea.

Disadvantages? You have to understand how to do it correctly, and that takes
some study.
Peter

 

[Vadym Stetsyak]

Hello, GVN!

G> Can anyone guide me when asynchronous method calls will be
G> benificial?

Its up to app design. Async method calls are used when the caller
knows that operation will take a while, so she doesn't wait for method to complete
and instead can do some more usefull job ( render UI etc ).

Good example is network I/O. If you have GUI application it will not be good if UI
freezes every time you're receiving or sending data, right?

G> Are there any disadvantages of using asynchronous calls?
Usually making synchronous call is faster that async one.
This statement is valid only of method execution time is relatively small...

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

 

[steve.falzon@]

Hi All,

Can anyone guide me when asynchronous method calls will be
benificial? Are there any

disadvantages of using asynchronous calls?


Thanks,

GVN

The BackgroundWorker class makes implementing asynch methods a breeze.
Take a look at the page below it gives a decent explanation of why you
would use asynch calls and how to use the BackgroundWorker class.


http://msdn2.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx


cheers

Steve

 

[John Vottero]

Hi All,

Can anyone guide me when asynchronous method calls will be
benificial? Are there any

disadvantages of using asynchronous calls?

There have been some replies that confuse multithreading with asynchronous
method calls. The two aren't the same. Threadpools and backgroundworker
threads are great but, they don't solve the same problems that async method
calls can solve.

Another reply gave an example of checking 1000 RSS feeds with a pool of 30
threads. The asynchronous approach would be to issue 1000 BeginRead() so
you have 1000 outstanding async calls then, as the reads complete, the
AsyncCallback method is called.

If you were writing a CHAT server, you could create a new thread for each
client but, that wouldn't scale very far. With an async approach, you would
call BeginRead() for each client then, when the read completes, the
AsyncCallback would call BeginWrite() for each client that the incoming
message should be directed to and then call BeginRead() again to replace the
read that just completed. This would scale to thousands of clients with
just a few threads.

 

[Jeff Louie]

John.. I don't completely understand your point since from what I see
async
method calls to COM and BeginInvoke in C# are both implemented
internally
using threadpools.

Regards,
Jeff

Threadpools and backgroundworker

threads are great but, they don't solve the same problems that async
method
calls can solve.<

 

[steve.falzon@]

There have been some replies that confuse multithreading with asynchronous
method calls. The two aren't the same. Threadpools and backgroundworker
threads are great but, they don't solve the same problems that async method
calls can solve.

Another reply gave an example of checking 1000 RSS feeds with a pool of 30
threads. The asynchronous approach would be to issue 1000 BeginRead() so
you have 1000 outstanding async calls then, as the reads complete, the
AsyncCallback method is called.

If you were writing a CHAT server, you could create a new thread for each
client but, that wouldn't scale very far. With an async approach, you would
call BeginRead() for each client then, when the read completes, the
AsyncCallback would call BeginWrite() for each client that the incoming
message should be directed to and then call BeginRead() again to replace the
read that just completed. This would scale to thousands of clients with
just a few threads.

Hi John

Granted asynch calls and multithreading aren't the same thing.
However, it is often desirable to execute an asynch calls on it's own
thread, as is the case when trying to avoid an unresponsive UI in a
windows app for instance, the two methods can be used together. Or so
I thought.

If I'm mistaken I'd appreciate your advice on how best to approach
this. Assuming I'm not looking to scale to thousands of users, just a
single user using the app, how should I ensure the app remains
responsive whilst waiting for a request, to a webservice for instance,
to complete? For me the BackgroundWorker solves this problem and with
less effort than has previously been the case.

There are many ways to approach a problem and I'd be interested to
know how others might solve problems like this.

Cheers

Steve

 

[Jon Skeet [C# MVP]]

There have been some replies that confuse multithreading with asynchronous
method calls. The two aren't the same. Threadpools and backgroundworker
threads are great but, they don't solve the same problems that async method
calls can solve.

To be clear here - they aren't *always* the same. They sometimes are.
Basically when you use asynchronous *IO* you use IO completion ports
rather than a single thread per connection.

However, other types of asynchronous call (SomeDelegate.BeginInvoke,
Control.BeginInvoke etc) *are* just multithreading using the
threadpool.

 

[John Vottero]

John.. I don't completely understand your point since from what I see
async
method calls to COM and BeginInvoke in C# are both implemented
internally
using threadpools.

The only point I was trying to make is that there's a difference between
multithreaded programming (which is inherently asynchronous) and
asynchronous method calls. It's important to understand the difference
between calling ThreadPool.QueueUserWorkItem and BeginRead. I'm not saying
that one is better than the other, they're just different.

 

[John Vottero]

Hi John

Granted asynch calls and multithreading aren't the same thing.
However, it is often desirable to execute an asynch calls on it's own
thread, as is the case when trying to avoid an unresponsive UI in a
windows app for instance, the two methods can be used together. Or so
I thought.

I didn't mean to imply that asynch calls were better than multithreading, I
just wanted to point out the difference.

If I'm mistaken I'd appreciate your advice on how best to approach
this. Assuming I'm not looking to scale to thousands of users, just a
single user using the app, how should I ensure the app remains
responsive whilst waiting for a request, to a webservice for instance,
to complete? For me the BackgroundWorker solves this problem and with
less effort than has previously been the case.

I use BackgroundWorker threads all the time, I think they're great. But, if
you might have hundreds of outstanding webservice calls, you probably don't
want to have a thread for each one of them.

 

[Willy Denoyette [MVP]]

| > There have been some replies that confuse multithreading with
asynchronous
| > method calls. The two aren't the same. Threadpools and
backgroundworker
| > threads are great but, they don't solve the same problems that async
method
| > calls can solve.
|
| To be clear here - they aren't *always* the same. They sometimes are.
| Basically when you use asynchronous *IO* you use IO completion ports
| rather than a single thread per connection.
|
| However, other types of asynchronous call (SomeDelegate.BeginInvoke,
| Control.BeginInvoke etc) *are* just multithreading using the
| threadpool.

What makes you think that Control.BeginInvoke uses the threadpool?, it
simply queues a delegate and posts a message to the windows message queue
associated with the Control's HWND, the threadpool is not used here.
Willy.

 

[Jon Skeet [C# MVP]]

What makes you think that Control.BeginInvoke uses the threadpool?, it
simply queues a delegate and posts a message to the windows message queue
associated with the Control's HWND, the threadpool is not used here.

Sorry, yes - don't know what I was thinking of there. I'm pretty sure
about Delegate.BeginInvoke though