Library tutorials & articles

.NET Threading Part I

Creating Threads

Creating a thread in C# is close to trivial, but not quite. The only non-trivial thing about creating a thread is .NET delegate-classes. Let me explain in few words what is a delegate class. The delegate is a wrapper around a code construct in the .NET. The code construct could be an object instance, an instance method or a static method.

Delegates are used when you want to pass one of the three code constructs as a parameter to another method. When creating a new thread you have to use the ThreadStart delegate class to wrap the instance method that will be executed in the newly created thread. The instance method must return void and must not have any parameters.

void ThreadStart()

To create a new thread, first create a new ThreadStart object, passing the instance method of the thread procedure in the constructor. The new delegate object is then passed to the constructor of the Thread.

Thread thread = new Thread(
    new ThreadStart(obj.ThreadStart));

You've now created a new thread, but the thread is not yet started. To start the thread, you call the Thread.Start instance method.

thread.Start();

And that's it. You have a new running thread. A complete console application that creates a thread and outputs a couple messages to the console window is shown below.

using System;
using System.Threading;
namespace ConsoleApplication1
{
    class Class1
    {
        static void PrintHelloFromThreadName()
        {
            Console.WriteLine("Hello, from thread {0}",
                Thread.CurrentThread.Name); // {0}
        }

        public void ThreadStart()
        {
            PrintHelloFromThreadName();
        }

        static void Main(string[] args)
        {
            Thread.CurrentThread.Name = "Main thread";
            Class1 obj = new Class1();
            Thread thread = new Thread(
                new ThreadStart(obj.ThreadStart));
            thread.Name = "Forked thread";
            thread.Start();
            PrintHelloFromThreadName();
        }
    }
}

A nice feature of .NET threads, and for that matter any .NET object, is the ability name the object. If you name your threads, then the debugger will pick up those names and you'll have a much easier time debugging (see Figure 1). The frame in the bottom left of the IDE window in Figure 1 shows all the threads in out C# application. I set a breakpoint in the PrintHelloFromThread Name static method in Listing 1 and ran the application. When the application stops on the breakpoint, I called up the threads window from the menu bar, Debug | Window | Threads. As you can see, the Name in the threads window of the IDE is the same as the name given the Thread object in our C# code.

Comments

  1. 27 Feb 2004 at 22:06

    I was asked to do the following:
    write the method call to begin running the thread and begin processing
    (a) namespace = testProject
    (b) form to run = frmMain


    All the things that I have read on threading so far say that a thread point to a function of whatever comes after the "addressOf" in the argument.  Therefore, I don't understand what (a) and (b) are trying to refer to or specify.  If you happen to understand what that question is looking for, or know any good literature I can look at for the given topic, please let me know.  Thank you.
    email me

  2. 04 Nov 2003 at 15:04
    Quote:
    [1]Posted by James Crowley on 4 Nov 2003 02:52 PM[/1]
    Are you ensuring that the page doesn't finish loading before both threads have returned a result? Otherwise, you may find that ASP.NET is outputting the page to the client before the thread has actually called the callback!



    Yes...and if I may add, rather hesitantly at this juncture, I did think about that.
    What surprised me however was when I ran this in debugging mode, I as able to trace both callbacks
    and in one case the dataset returned had no data. I wonder if  there are any issues with returning non-simple types
    in the event driven call back. May be, using the delegate mechanism may work. I havn't done
    much callback based threading so far...
  3. 04 Nov 2003 at 14:52
    Are you ensuring that the page doesn't finish loading before both threads have returned a result? Otherwise, you may find that ASP.NET is outputting the page to the client before the thread has actually called the callback!
  4. 04 Nov 2003 at 13:20
    I have tried threading in my web page. I tried to fill two drop-downs by threading two methods in two different business layer objects from my web page. I used the event call back method  to return two datasets (one for each drop down) but got  inconsistent results..drop-downs were populated and sometimes not. Any ideas?
  5. 01 Jan 1999 at 00:00

    This thread is for discussions of .NET Threading Part I.

Leave a comment

Sign in or Join us (it's free).

Randy Charles Morin Randy's article are Copyright 1998-2003 Randy Charles Morin

Related podcasts

  • A Practical Look at Silverlight 2 Part 1

    Now that Silverlight 2 is at the Olympics and making a big splash, we wanted to explore this fascinating technology more. Microsoft Silverlight 2 is a cross-browser, cross-platform, and cross-device plug-in for delivering the next generation of .NET based media experiences and rich interactive ap...

Events coming up

  • Dec 9

    GL.net Group Meeting - December 2009

    Gloucester, United Kingdom

    The beginning of this year holiday season will belong to mocks. Ronnie and Stephen will take us for a tour around exciting world of unit testing.

Want to stay in touch with what's going on? Follow us on twitter!