dotnet clr:
[quoted text, click to view]

.. . .

[quoted text, click to view]


System.Threading.Thread.CurrentThread.ManagedThreadId

David

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

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

"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:OGJayXE9FHA.3592@TK2MSFTNGP12.phx.gbl...
[quoted text, click to view]

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.

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;
}

Hi!

[quoted text, click to view]

Because managed Threads must not be implemented as OS - Threads. You cannot
assume that a managed Thread has always an unmanaged counterpart.

[quoted text, click to view]

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.

[quoted text, click to view]

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