Discussion:
Alternative to AppDomain.GetCurrentThreadId.
(too old to reply)
Davinci
2005-11-28 17:14:55 UTC
Permalink
In .NET 2.0 if you use AppDomain.GetCurrentThreadId then you will get a
warning that the call is obsolete and you should use ManagedThreadId
property of the Thread object.



If you were to look at the AppDomain.GetCurrentThreadId() method and
Thread.ManagedThreadId property documentation you will notice that they do
not accomplish the same task. Yes, they both give you a Thread ID but
GetCurrentThreadId() gives you the current running thread when it is called
and the ManagedThreadId gives you the thread Id of the Instance of a
“System.Threading.Thread” object.



That said you are not getting what you want when you want it if you simply
replaced GetCurrentThreadId with ManagedThreadID.



Allow me to show you how GetCurrentThreadId will be used in a application
but first look at how it is used behind the seen.



private void button1_Click(object sender, EventArgs e)

{

lock (label1)

{

ChangeBtn();

}

}



private void ChangeBtn()

{



lock (label1)

{

Button1.Text = "ok";

}

}





The above code works fine the button’s caption changes from “Button1” to
“ok” with no problems. Why? Because in the method ChangeBtn() the CLR
checked the thread ID of when you last locked the label1 and it was done in
the same thread. So the since the lock was none in the same thread then the
execution will continue and will not deadlock.



Now lets just say I knew that a method could not be executed in a particular
thread and if it did a deadlock would occur I would save my Thread ID that
the code would should not execute with and then test it against the current
thread the method was called.



private void button4_Click(object sender, EventArgs e)

{

if (FSaveLabelThreadID != AppDomain.GetCurrentThreadId())

{

MySemaphore.Enter;

try

{

ChangeBtn();

}

finally

{

MySemaphore.Leave;

}

}

else

throw new Exception("Deadlock will occur");

}



private void ChangeBtn()

{

if (FSaveLabelThreadID != AppDomain.GetCurrentThreadId())

{

MySemaphore.Enter;

try

{

button4.Text = "ok";

}

finally

{

MySemaphore.Leave;

}

}

else

throw new Exception("Deadlock will occur");

}





So my question is how would I replace AppDomain.GetCurrentThreadId() so that
I can find out what thread my code is running under?





Thanks



Davinci
David Browne
2005-11-28 18:02:48 UTC
Permalink
Post by Davinci
In .NET 2.0 if you use AppDomain.GetCurrentThreadId then you will get a
warning that the call is obsolete and you should use ManagedThreadId
property of the Thread object.
If you were to look at the AppDomain.GetCurrentThreadId() method and
Thread.ManagedThreadId property documentation you will notice that they do
not accomplish the same task. Yes, they both give you a Thread ID but
GetCurrentThreadId() gives you the current running thread when it is
called and the ManagedThreadId gives you the thread Id of the Instance of
a “System.Threading.Thread” object.
That said you are not getting what you want when you want it if you simply
replaced GetCurrentThreadId with ManagedThreadID.
. . .
Post by Davinci
So my question is how would I replace AppDomain.GetCurrentThreadId() so
that I can find out what thread my code is running under?
System.Threading.Thread.CurrentThread.ManagedThreadId

David
Davinci
2005-11-30 14:20:23 UTC
Permalink
Thanks

I can't believe I missed that static property....

System.Threading.Thread.CurrentThread

I guess I am not use the .NET yet with its instantiated objects that have
static methods AND properties that uses themselves. I come from Delphi and
although it could be done in the language it wasn't. This is because global
methods where used and they could have friendly relations (access to private
members) with an object.

Davinci
Post by David Browne
Post by Davinci
In .NET 2.0 if you use AppDomain.GetCurrentThreadId then you will get a
warning that the call is obsolete and you should use ManagedThreadId
property of the Thread object.
If you were to look at the AppDomain.GetCurrentThreadId() method and
Thread.ManagedThreadId property documentation you will notice that they
do not accomplish the same task. Yes, they both give you a Thread ID but
GetCurrentThreadId() gives you the current running thread when it is
called and the ManagedThreadId gives you the thread Id of the Instance of
a "System.Threading.Thread" object.
That said you are not getting what you want when you want it if you
simply replaced GetCurrentThreadId with ManagedThreadID.
. . .
Post by Davinci
So my question is how would I replace AppDomain.GetCurrentThreadId() so
that I can find out what thread my code is running under?
System.Threading.Thread.CurrentThread.ManagedThreadId
David
Jeffrey Tan[MSFT]
2005-12-01 01:34:55 UTC
Permalink
Yes, we sometimes missed the simplest thing, fortunately, some other people
can point out the clear way for us :-).

If you still have any concern on this, please feel free to feedback. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
pam scheichenost
2006-10-30 22:35:46 UTC
Permalink
I'm trying to create a hook using 2.0 following the below example, but
the AppDomain.GetCurrentThreadID is now obsolete. I have tried
replacing it with Thread.CurrentThread.ManagedThreadID, but it returns
0, so it is failing. What do I need to do to get this to work??

hHook = SetWindowsHookEx(WH_MOUSE,
MouseHookProcedure, (IntPtr)0, AppDomain.GetCurrentThreadId());

//If the SetWindowsHookEx function fails.
if(hHook == 0 )
{
MessageBox.Show("SetWindowsHookEx Failed");
return;
}



*** Sent via Developersdex http://www.developersdex.com ***
unknown
2006-10-31 10:13:59 UTC
Permalink
Hi!
Post by pam scheichenost
I'm trying to create a hook using 2.0 following the below example, but
the AppDomain.GetCurrentThreadID is now obsolete.
Because managed Threads must not be implemented as OS - Threads. You cannot
assume that a managed Thread has always an unmanaged counterpart.
Post by pam scheichenost
I have tried
replacing it with Thread.CurrentThread.ManagedThreadID, but it returns
0, so it is failing.
It is not failing. The Thread.ManagedThreadID property is just an Identifier
which is unique within your process. The MangededThreadID is no handle or a
OS-ThreadID.
Post by pam scheichenost
What do I need to do to get this to work??
Because the current CLR implements managed Threads with OS-Threads, you can
still use the AppDomain.GetCurrentThreadID Method. But if you program runs
on a CLR that do not use OS Threads to implement managed Threads (what about
the SQL 2005 CLR? I can configure the SQL-Server to use fibers instead of
Threads. Maybe the SQL CLR uses Fibers also for managed Threads? It would be
possible to check this), you application will fail.

Another possiblity would be to use the unmanaged GetCurrentThreadId
function:

http://msdn.microsoft.com/library/en-us/dllproc/base/getcurrentthreadid.asp

[DllImport("kernel32.dll")]
static extern int GetCurrentThreadId();




OK?

GP

Loading...