Thread class - using lock object

Mrinal,

For the code that you listed, you don't need the lock at all.

You are looking to assign to the value of the current thread, which will
be different for every thread that this routine is called on. Since that is
the case, you don't have to worry about multiple threads accessing the
value.

It should also be noted that you shouldn't use the static
GetCurrentThreadId method on the AppDomain class anymore, since it is not
guaranteed to give you an id which corresponds to the current thread.
Threads in .NET are no longer mapped to physical threads on the machine.
They are logical entities and should be treated as such.

In general, when you are working with threads, you need to use a lock
statement to synchronize access between threads when they share a common
resource. Since you are not sharing anything here, it's a non-issue.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Mrinal Kamboj" <mr***********@oracle.com> wrote in message
news:6N**************@news.oracle.com...

Hi ,

I had a doubt regarding a piece of code with me , that has to do with
System.Threading.Thread class .

In it user instantiates an array of Thread class and to all of them assign
a method for execution using ThreadStart Delegate say "worker" method .

Now in the worker method there's a piece of code :

lock (typeof(<ClassName>))
{
try
{
Thread.CurrentThread.Name = AppDomain.GetCurrentThreadId().ToString();
}
catch (System.Exception ex)
{
// Exception code
}
}

where as you can see there's a Synchronized region been created using lock
keyword .

However , what i think is , this is not required since , Worker method is
an instance method and every thread will execute it's own separate method
, so , there's no need , but then another point is all this code is as a
part of an exe , which has only one instance created at any point of time
, so it seems may be required even .

Any comments regarding this ?

thanks ,

Mrinal

Nicholas ,

Thanks again , but few things , i agree Thread class in .Net is a
logical wrapper , but then underlying unmanaged implementation should
correspond to OS threads , essentially , what i mean is on doing :

Thread t = new Thread(<Threadstart delegate>) ;

it should spawn a corresponding entity in the OS and on using Appdomain
static method , i should be able to get the relevant id . What are your
views regarding this .

also , what if i use :

[DllImport("kernel32.dll", EntryPoint="GetCurrentThreadId")]
public static extern uint GetCurrentThreadId();

so , it will be :

Thread.CurrentThread.Name = GetCurrentThreadId().ToString() ;

instead of Appdomain's static method , is it doing the same thing .

regards ,

Mrinal
Nicholas Paldino [.NET/C# MVP] wrote:

Mrinal,

For the code that you listed, you don't need the lock at all.

You are looking to assign to the value of the current thread, which will
be different for every thread that this routine is called on. Since that is
the case, you don't have to worry about multiple threads accessing the
value.

It should also be noted that you shouldn't use the static
GetCurrentThreadId method on the AppDomain class anymore, since it is not
guaranteed to give you an id which corresponds to the current thread.
Threads in .NET are no longer mapped to physical threads on the machine.
They are logical entities and should be treated as such.

In general, when you are working with threads, you need to use a lock
statement to synchronize access between threads when they share a common
resource. Since you are not sharing anything here, it's a non-issue.

Hope this helps.

NO. You CAN NOT do this in .NET 2.0. It is not guaranteed that there
will be a one-to-one relationship between a thread id and a managed thread
in .NET.

In .NET 1.1 and before, you could do this, but it wouldn't work in .NET
2.0 and beyond, since multiple Threads can actually execute on the same OS
thread.

If you need a unique identifier for a thread, then use the
ManagedThreadId property on the Thread instance.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Mrinal Kamboj" <mr***********@oracle.com> wrote in message
news:43**************@oracle.com...

Nicholas ,

Thanks again , but few things , i agree Thread class in .Net is a logical
wrapper , but then underlying unmanaged implementation should correspond
to OS threads , essentially , what i mean is on doing :

Thread t = new Thread(<Threadstart delegate>) ;

it should spawn a corresponding entity in the OS and on using Appdomain
static method , i should be able to get the relevant id . What are your
views regarding this .

also , what if i use :

[DllImport("kernel32.dll", EntryPoint="GetCurrentThreadId")]
public static extern uint GetCurrentThreadId();

so , it will be :

Thread.CurrentThread.Name = GetCurrentThreadId().ToString() ;

instead of Appdomain's static method , is it doing the same thing .

regards ,

Mrinal
Nicholas Paldino [.NET/C# MVP] wrote:

Mrinal,

For the code that you listed, you don't need the lock at all.

You are looking to assign to the value of the current thread, which
will be different for every thread that this routine is called on. Since
that is the case, you don't have to worry about multiple threads
accessing the value.

It should also be noted that you shouldn't use the static
GetCurrentThreadId method on the AppDomain class anymore, since it is not
guaranteed to give you an id which corresponds to the current thread.
Threads in .NET are no longer mapped to physical threads on the machine.
They are logical entities and should be treated as such.

In general, when you are working with threads, you need to use a lock
statement to synchronize access between threads when they share a common
resource. Since you are not sharing anything here, it's a non-issue.

Hope this helps.

Hi Mrinal,

Thanks for Nicholas's reply. I just wanted to check how things are going
and whether or not Nicholas's suggestion solve your problem.

If there is any question, please feel free to join the community and we are
here to support you at your convenience. Thanks again and have a nice day!

Best Regards,

Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)