Naming, passing data and capturing variables in Thread

Naming Thread

We know that every thread has a Name property that you can set for the benefit of debugging. Thread's name is displayed in the Threads Window and Debug Location toolbar. The static Thread.CurrentThread property gives you the name of current thread. You can set the Name property once in visual studio if we try to change it again this will throw a exception.

In the following example, we implement the Thread.CurrentThread property for naming the thread.

using System;
using System.Diagnostics;
using System.Threading;
namespace Threadnaming
{
class Program
{
static void Run()
{
Console.WriteLine("welcome to the " + Thread.CurrentThread.Name +" world");
}

static void Main(string[] args)
{
Thread.CurrentThread.Name = "MCN";
Thread website = new Thread(Run);
website.Name = "C#Corner";
website.Start();
Run();
Console.Read();
}
}
}

Output

ing Data to a Thread

We can arguments to a thread's target method is to execute a lambda expression that calls the method with the desired arguments. With this approach, you can supply in any number of arguments to the method.

using System;
using System.Threading;
using System.Diagnostics;
namespace ingdatatoathread
{
class Akshay
{
static void display(string message)
{

Console.WriteLine(message);
}
static void Main(string[] args)
{
Thread th = new Thread(() => Console.WriteLine("Hello from th!"));
th.Start();
Console.Read();
}
}
}

Output

You can even wrap the entire implementation in a multi-statement lambda:

new Thread(() =>
{
Console.WriteLine("I'm processing on another thread!");
Console.WriteLine("This is so easy!");
}).Start();

Lambda expressions and captured variables

As we saw, a lambda expression is the esay way to data to a thread. However, You need to keep care when abnormally modifying captured variables after thread is start, because these variables are shared. For instance, consider the following:

for (int i = 0; i < 10; i++)
new Thread(() => Console.Write(i)).Start();

The output of above program is unaccepted

0223557799

The problem is that the 'i' variable refers throughout the loop's lifetime same memory location. Therefore, each thread calls Console.Write on a variable whose value may change as it is running! The solution is to use a temporary variable as follows:

for (int i = 0; i < 10; i++)
{
int temp = i;
new Thread(() => Console.Write(temp)).Start();
}

Now temp variable work like a local variable for each iteration of loop. therefore the problem is solve because each thread captures a different memory location.

you can simplified the above code as:

string text = "t1";
Thread t1 = new Thread(() => Console.WriteLine(text));
text = "t2";
Thread t2 = new Thread(() => Console.WriteLine(text));
t1.Start();
t2.Start();

Because both lambda expressions capture the same text variable, t2 is printed twice as.

t2
t2

Foreground and Background Threads

Foreground thread are used to alive are application as long as any of the thread is running .By default, threads you create explicitly are foreground threads. whereas background threads do not. Once all foreground threads finish, the application ends, and any background threads still running suddenly terminate.

You can query or change a thread's background status using its IsBackground property. Here's an example:

class PriorityTest
{
static void Main (string[] args)
{
Thread emp = new Thread ( () => Console.ReadLine() );
if (args.Length > 0) emp.IsBackground = true;
emp.Start();
}
}

When we call this program with no argument the emp thread assumes foreground status and it will wait on the ReadLine statement for the user to press Enter. Meanwhile, the main thread exits, but the application is in the running mode because a foreground thread is still alive.

In another way , if you supply an argument to the Main(), the emp is assigned background status, and the program exits almost immediately as the main thread ends (terminating the ReadLine).

If a process terminate like as. this is happen because of your program employs finally (or using) blocks to perform cleanup work such as releasing resources or deleting temporary files. To overcome this problem you need to wait until explicitly background threads upon exiting an application. you can achieve this by to ways.

If you've created the thread yourself, call Join on the thread.
If you're on a pooled thread, use an event wait handle.

Sometime u can give a timeout to abandon a renegade thread which is refuse to finish for some reason. This is your backup exit strategy: in the end, when you want to close your application without taking the help of Task Manger.

This process is not require for foreground thread. But you need to take care to avoid bugs that could cause the thread not to end. Some time the presence of active foreground thread create hurdle for termination or exit of any application.

When a user use the task manager forcefully terminate the .Net process then the all thread are dead as though they were background threads. This is observe fact rather than a documented data. and it could be differ depending on the version of CLR and operating system.