Threads and asychronous operations.. how are they different

[gs_sarge]

Hi:

I have a couple of questions about threads and asynchronous calls

Question 1: How are these two different?

Situation a:

Caller calls method1 with parameters

Method1 takes parameters from caller,
creates an object with those parameters
passed in to be stored by the object as member variable,
calls a thread method on the object,
starts thread and returns.

Situation b:

Caller calls method2 with parameter

Method2 takes parameters from caller,
creates async delegate for a method in its class,
calls asynchronously the method, giving it a
callback function with the delegate as the last argument
and returns.

when the async call is complete, it calls the callback function
which takes the delegate object passed to it and endinvokes it.






Question 2:
If two different delegate wrappers for the same method are called back
to back, will they run concurrently on the system, or does the second
method call have to wait for the first one to finish before executing.
Of course for this I would pass in a callback function that would
handle the endinvoke. In that way, at least from the outside, it
would look like they behaved like threads. But what about internally.
Would they truly behave like threads?


For my situation, if they behaved exactly like threads, it would be
very beneficial to me. I find greater flexibility with asynchronous
calls because I can pass in parameters. Of course, if I created
objects to do my work in a thread, I could give it parameters to hold
as member variables, but that would require creating an additional
object. But if I wanted to use a class method to do the work, using a
thread would prevent me from passing in parameters. With async calls,
I can pass in a reference parameter, which could be modified by the
async call. I could then check the state of the reference parameter.
In this sense, I can pass in parameters and get return values (could
also just use an out variable).






Question 3:

If a delegate is passed to a function as a ref parameter, and it has a
method that can be threaded, can that method be threaded by the
function and let to do it's work. And if so, if thread modified its
object's state information, would those changes be seen by the
original object passed?

If both caller and function are in the app domain, it really isn't
that important to me? But what if they are in different domains? For
example, what if the caller is using a remote object, and passing in a
delegate object that will be threaded on the remote machine. In which
domain is the thread running?



Answers to these questions will be greatly appreciated and will help
me in my understanding of multi-threading in C# and .NET

Steve

 

[Richard Grimes [MVP]]

Question 1: How are these two different?

Every process has a pool of threads. You do not control this pool. Async
calls are made on a pool thread. If you create your own worker thread you
chose what happens to that thread, how its initialized. If you use a pool
thread then you ensure that there is a limit on the number of threads that
will be created in your process, which is a good thing. Creatuing lots of
threads is a bad thing and has a *bad* effect ion performance.

So in general, yes create worker threads if you have a special need for how
they are initialized, but keep them to a minimum. If you just want a general
purpose thread then use a pool thread, and async delegate calls is one way
to do this.

Another advantage of async calls is that you can have 'fire and forget' that
is, if the method has no return values you can mark it with [OneWay], and
*nothing* will be returned back to the calling thread, so you don't need to
call EndInvoke(). [OneWay] will also suppress exceptions.

Question 2:
If two different delegate wrappers for the same method are called back
to back, will they run concurrently on the system, or does the second
method call have to wait for the first one to finish before executing.

Depends how you call it. If you call it through async methods then a pool
thread will be used, and if the pool is busy one call might be made and the
other call might be delayed until the thread that was used by the first call
is available.

Of course, if you have a single processor machine only one method will be

Of course for this I would pass in a callback function that would
handle the endinvoke. In that way, at least from the outside, it
would look like they behaved like threads. But what about internally.
Would they truly behave like threads?

Async calls are called on threads other than the thread that initialized the
call.

For my situation, if they behaved exactly like threads, it would be
very beneficial to me. I find greater flexibility with asynchronous
calls because I can pass in parameters. Of course, if I created
objects to do my work in a thread, I could give it parameters to hold
as member variables, but that would require creating an additional
object.
But if I wanted to use a class method to do the work, using a
thread would prevent me from passing in parameters. With async calls,
I can pass in a reference parameter, which could be modified by the
async call. I could then check the state of the reference parameter.
In this sense, I can pass in parameters and get return values (could
also just use an out variable).

Remember that you should becareful about multiple threads accessing the
state object. The WaitCallback delegate is called on the pool thread, not
the thread that initiates the async call.

Question 3:

If a delegate is passed to a function as a ref parameter, and it has a
method that can be threaded, can that method be threaded by the
function and let to do it's work.

I don't understand what you mean by 'threaded'.

Richard

 

[Steve Sargent]

thank you for the info. It was very helpful.

Question 1: How are these two different?

Every process has a pool of threads. You do not control this pool. Async
calls are made on a pool thread. If you create your own worker thread you
chose what happens to that thread, how its initialized. If you use a pool
thread then you ensure that there is a limit on the number of threads that
will be created in your process, which is a good thing. Creatuing lots of
threads is a bad thing and has a *bad* effect ion performance.

So in general, yes create worker threads if you have a special need for how
they are initialized, but keep them to a minimum. If you just want a general
purpose thread then use a pool thread, and async delegate calls is one way
to do this.

Another advantage of async calls is that you can have 'fire and forget' that
is, if the method has no return values you can mark it with [OneWay], and
*nothing* will be returned back to the calling thread, so you don't need to
call EndInvoke(). [OneWay] will also suppress exceptions.

Question 2:
If two different delegate wrappers for the same method are called back
to back, will they run concurrently on the system, or does the second
method call have to wait for the first one to finish before executing.

Depends how you call it. If you call it through async methods then a pool
thread will be used, and if the pool is busy one call might be made and the
other call might be delayed until the thread that was used by the first call
is available.

Of course, if you have a single processor machine only one method will be

Of course for this I would pass in a callback function that would
handle the endinvoke. In that way, at least from the outside, it
would look like they behaved like threads. But what about internally.
Would they truly behave like threads?

Async calls are called on threads other than the thread that initialized the
call.

For my situation, if they behaved exactly like threads, it would be
very beneficial to me. I find greater flexibility with asynchronous
calls because I can pass in parameters. Of course, if I created
objects to do my work in a thread, I could give it parameters to hold
as member variables, but that would require creating an additional
object.
But if I wanted to use a class method to do the work, using a
thread would prevent me from passing in parameters. With async calls,
I can pass in a reference parameter, which could be modified by the
async call. I could then check the state of the reference parameter.
In this sense, I can pass in parameters and get return values (could
also just use an out variable).

Remember that you should becareful about multiple threads accessing the
state object. The WaitCallback delegate is called on the pool thread, not
the thread that initiates the async call.

Question 3:

If a delegate is passed to a function as a ref parameter, and it has a
method that can be threaded, can that method be threaded by the
function and let to do it's work.

I don't understand what you mean by 'threaded'.

Richard