views:

129

answers:

3

As i can perform asynchronous operations using delegates,i suspect there is a thin chance to use System.Threading in my application.Is there any essential situation where i can not avoid System.Threading ?

( Just I am in learning Phase).

Example :

class Program

{

public delegate int Total (int a,int b);

static void Main()

{

  Total tl = new Total(SumUp);
  IAsyncResult isany=tl.BeginInvoke(20,20, null, null);

    while (!isany.IsCompleted)
    {
        Console.WriteLine("Busy with other work");
    }

    int ans = tl.EndInvoke(isany);

    Console.WriteLine("Result ={0}", ans);

}

static int SumUp(int a,int b)

{
    a = a * a;

    b = b * b;

    return a + b;

}
}
A: 

do i still need System.Threading

What do you mean by "need"? The types of System.threading are defined in the mscorlib assembly which is always loaded. You only need to say using System.Threading if you want to avoid fully qualified names in your code.

Richard
+4  A: 

We are constantly getting better and better abstractions that deal with concurrency, so the more low-level constructs are often not necessary.

You already found one example of such a higher-level abstraction, and .NET 4.0 will give us some new and very powerful ways of dealing with concurrent code, such as Tasks and continuations.

As time goes by, you should be able to deal with concurrency at higher and higher levels of abstractions. Whether those abstractions live in System.Threading or not is, in my opinion, less important.

Mark Seemann
+2  A: 

Asynchronous delegates run on the thread pool, as detailed here. One situation I've had to use an explicit Thread was to run a UI task in the background, as the thread pool threads are all multithreaded apartment, and UI tasks can only be run in a singlethreaded apartment. The link above also gives a few more situations where it is not appropriate to use the thread pool.

Although most short-lived background tasks should be done using the thread pool or asynchronous delegates, there will still be situations in which you need to create an explicit thread. System.Threading isn't going away anytime soon.

thecoop
thecoop has it right . . . Implied by his answer is that thread pool threads are a limited resource. A good excercise for you would be to write a small package that simulated the Begin/EndInvoke functionality on non-threadpool threads. You could implement IAsyncResult, generic methods, callbacks and other goodies to round out this package.
TheEruditeTroglodyte