Asynchronous Programming Model

[Guest]

Hi everyone,
I need to refactor some of our processes using the asynchronous programming
model. I have defined a couple of arrays of delegates to pipline the
asynchronous invocations through different stages of execution.
However I was wondering if there was any information available regarding the
limitations of the asynchronous model, in particular maximum numbers of
asynchronous elements, and limitations of multiple requests potentially
queuing up to call the same callback, and also any information regarding
exception management in the apm. Thanks for any input.

 

[Guest]

I should probably add, the delegates are added to an available pool of
delegates, when they are assigned they are removed from the pool. when work
is complete and the callback is invoked, the delegate is added back to the
pool and may now be reused by other pending items. I am particularly
concerned that exceptions could prevent the callback from taking place and
therefore leak resources, not to mention that the delegate would never return
to the available pool.

 

[Yuancai \(Charlie\) Ye]

Hi, mk:

You may see our SocketPro at www.udaparts.com, which is written using
bacthing, asynchrony and parallel computation with online compression.

You may investiage a set of tutorials at
http://www.udaparts.com/document/articles/tutorials.htm.

Wish it is useful to your development.

 

[Peter Duniho]

I should probably add, the delegates are added to an available pool of
delegates, when they are assigned they are removed from the pool. when
work is complete and the callback is invoked, the delegate is added back
to the pool and may now be reused by other pending items. I am
particularly concerned that exceptions could prevent the callback from
taking place and therefore leak resources, not to mention that the
delegate would never return to the available pool.

I'm not sure what you mean there. A delegate isn't a resource that can be
consumed. It's simply a way of describing a method to be called. There
should be no need to manage the allocation of delegates or to maintain any
sort of pool of delegates. You can keep as many references to the same
delegate as you like, and call any of those references any time you like
(within the usual rules of using a delegate, of course).

Since there's no need to manage a pool of delegates, there is also no
concern about whether an exception will result in a delegate not being
returned to the pool.

As for your original question, it's not very clear what it is exactly you
mean to do. However, generally speaking any limitations regarding queuing
of asynchronous methods would be dependent on your own implementation of
that. One common way to process tasks asynchronously is to use the
BackgroundWorker class, and in that case the only real limitation there is
how many threads can actually be active concurrently. If you reach that
limit, new work items are queued.

Perhaps you should look at the kind of functionality BackgroundWorker
gives you, try to actually implement your code using that, and then if you
run into problems post new questions in this newsgroup (or even better,
the microsoft.public.dotnet.framework newsgroup, since it doesn't appear
your question is actually C#-specific), including more details about what
you're actually doing than you've provided so far.

Pete