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.
Related articles
Related discussion
-
hey developers out there
by pitsophera (0 replies)
-
How can i develop opc server using .net?
by vairajaig (1 replies)
-
Creating a Windows Service in VB.NET
by davidvanr (108 replies)
-
High-Performance .NET Application Development & Architecture
by Manjot Bawa (0 replies)
-
An Introduction to VB.NET and Database Programming
by carlosmen (14 replies)
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.
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
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...
This thread is for discussions of .NET Threading Part I.