Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / October 2006

Tip: Looking for answers? Try searching our database.

Alternative to AppDomain.GetCurrentThreadId.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Davinci - 28 Nov 2005 17:14 GMT
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 - 28 Nov 2005 18:02 GMT
> 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
[quoted text clipped - 9 lines]
> That said you are not getting what you want when you want it if you simply
> replaced GetCurrentThreadId with ManagedThreadID.

. . .

> 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 - 30 Nov 2005 14:20 GMT
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

>> 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
[quoted text clipped - 18 lines]
>
> David
"Jeffrey Tan[MSFT]" - 01 Dec 2005 01:34 GMT
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
Signature

Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

pam scheichenost - 30 Oct 2006 23:35 GMT
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;
}
Günter Prossliner - 31 Oct 2006 11:13 GMT
Hi!

> 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.

> 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.

> 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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.