Library tutorials & articles
.NET Threading Part I
- Introduction
- Creating Threads
- Thread Pools
- Synchronization Objects
- Race Condition
- Join
- AutoResetEvent & Timer
AutoResetEvent & Timer
Early in the article, I introduced you to the ManualResetEvent
class. This class allowed you to set and reset (signal and unsignal) the event
by calling the Set and Reset instance methods. The
System.Threading.AutoResetEvent class is very similar to the ManualResetEvent
class, but when a thread waiting on the event is signaled, the one thread is
released and the event is returned to the unsignaled state. This removes the
necessity to reset the signal after a thread is signaled.
Another great class in the System.Threading namespace is the Timer
class. This class allows you to signal an event at a particular interval in
time in the future. The Timer class is implemented using a delegate
callback instance method. When the Timer is signaled, the class
calls the instance method that you specified in the constructor of the Timer
object. The Timer callback can also receive a parameter object
passed in the call to the Timer constructor. Presented below is
a small sample using the AutoResetEvent and Timer
classes.
using System;
using System.Threading;
namespace ConsoleApplication8
{
class Class1
{
public void TimerCallback(Object obj)
{
Console.WriteLine("Timer triggered");
((AutoResetEvent) obj).Set();
Thread.Sleep(1000);
((AutoResetEvent) obj).Set();
}
static void Main(string[] args)
{
Class1 obj = new Class1();
AutoResetEvent ev =
new AutoResetEvent(false);
Timer timer = new Timer(
new TimerCallback(obj.TimerCallback),
ev, 1000, 0);
ev.WaitOne();
Console.WriteLine("Event Fired");
ev.WaitOne();
Console.WriteLine("Event Fired");
}
}
}
Note that the Timer callback instance method is wrapped in a TimerCallback
delegate object. The main thread will create an AutoResetEvent
object and a Timer object. The main thread then waits on the event
object. The TimerCallback instance method is called after one second,
triggering the event object. Because the event object is automatically reset,
when the main thread attempts to wait on the event again, the thread yields
until the event is signaled a second time. The TimerCallback instance
method waits another second and then signals the event a second time, releasing
the main thread.
More
In the second part of this article, I will complete my discussion of the synchronization objects and will discuss thread local storage, COM interoperability and thread states.
Related articles
Related discussion
-
Creating a Windows Service in VB.NET
by Templario55 (107 replies)
-
High-Performance .NET Application Development & Architecture
by Manjot Bawa (0 replies)
-
An Introduction to VB.NET and Database Programming
by carlosmen (14 replies)
-
Compatibility Issue on Firefox to display on Cursor Location
by dinc3r (1 replies)
-
VB/VB.NET
by surath (7 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
-
Nov
18
15 Minutes of Fame
Dresher, United States
This is a yearly tradition. We select 10 of the favorite speakers from monthly meetings, code camps, and hands on labs. Each one does a 15 minute talk on their favorite .NET technology. This is our 10th anniversary so we plan a gala event with special prizes and refreshments.
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.