thread ID
-
Thanks Luc, 1. My application is pure C# application, and I want to dump thread ID to detect the behavior of each thread, so that I can find deadlock/re-entrance/how many times a thread enters a specific method, something like this. After reading document, I am confused whether I can use ManagedThreadId property, my concern is for example, whether two threads will map to the same ManagedThreadId, so that the monitor is not accurate to serve my purpose. 2.
Luc Pattyn wrote:
As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least.
Why not can not be identified by ManagedThreadId? Could you show me a scenario please? :-) 3.
Luc Pattyn wrote:
What you can do is catch the managed thread ID when the thread gets created, attach a thread name to it (using a Hashtable/Dictionary), then keep track of your threads by asking them their ID, and look up the thread name you assigned earlier. But that is a rather clumsy workaround for a lernel shortcoming.
I am confused why ManagedThreadId is not enough? Could you show me a scneario when just using ManagedThreadId is not enough please? regards, George
grfgsfdg
-
grfgsfdg
?? regards, George
-
Thanks Luc, 1. My application is pure C# application, and I want to dump thread ID to detect the behavior of each thread, so that I can find deadlock/re-entrance/how many times a thread enters a specific method, something like this. After reading document, I am confused whether I can use ManagedThreadId property, my concern is for example, whether two threads will map to the same ManagedThreadId, so that the monitor is not accurate to serve my purpose. 2.
Luc Pattyn wrote:
As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least.
Why not can not be identified by ManagedThreadId? Could you show me a scenario please? :-) 3.
Luc Pattyn wrote:
What you can do is catch the managed thread ID when the thread gets created, attach a thread name to it (using a Hashtable/Dictionary), then keep track of your threads by asking them their ID, and look up the thread name you assigned earlier. But that is a rather clumsy workaround for a lernel shortcoming.
I am confused why ManagedThreadId is not enough? Could you show me a scneario when just using ManagedThreadId is not enough please? regards, George
ryrt ruyeuttruuer e re njsdrfg irire ergtri tegr regtrre reirtirtgiers rtretrtgre
-
ryrt ruyeuttruuer e re njsdrfg irire ergtri tegr regtrre reirtirtgiers rtretrtgre
Can you speak English please? :-) regards, George
-
Thanks Luc, 1. My application is pure C# application, and I want to dump thread ID to detect the behavior of each thread, so that I can find deadlock/re-entrance/how many times a thread enters a specific method, something like this. After reading document, I am confused whether I can use ManagedThreadId property, my concern is for example, whether two threads will map to the same ManagedThreadId, so that the monitor is not accurate to serve my purpose. 2.
Luc Pattyn wrote:
As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least.
Why not can not be identified by ManagedThreadId? Could you show me a scenario please? :-) 3.
Luc Pattyn wrote:
What you can do is catch the managed thread ID when the thread gets created, attach a thread name to it (using a Hashtable/Dictionary), then keep track of your threads by asking them their ID, and look up the thread name you assigned earlier. But that is a rather clumsy workaround for a lernel shortcoming.
I am confused why ManagedThreadId is not enough? Could you show me a scneario when just using ManagedThreadId is not enough please? regards, George
Hi George, ManagedThreadId is fine for identifying threads within .NET with two remarks: 1. it is a number, not a name; important stuff should be identified by name. 2. it does not map easily to the thread IDs as can be seen from other tools, such as Task Manager, SystemInfo, etc. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
Hi George, ManagedThreadId is fine for identifying threads within .NET with two remarks: 1. it is a number, not a name; important stuff should be identified by name. 2. it does not map easily to the thread IDs as can be seen from other tools, such as Task Manager, SystemInfo, etc. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
Thanks Luc, 1.
Luc Pattyn wrote:
2. it does not map easily to the thread IDs as can be seen from other tools, such as Task Manager, SystemInfo, etc.
Because Task Manager will use a different ID? And ManagedThreadId is just CLR internal thread ID? 2. What do you mean this before? -------------------- As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least. -------------------- Why no way? I think you mentioned in last post ManagedThreadId is ok to identify -- "ManagedThreadId is fine for identifying threads within .NET"? regards, George
-
Thanks Luc, 1.
Luc Pattyn wrote:
2. it does not map easily to the thread IDs as can be seen from other tools, such as Task Manager, SystemInfo, etc.
Because Task Manager will use a different ID? And ManagedThreadId is just CLR internal thread ID? 2. What do you mean this before? -------------------- As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least. -------------------- Why no way? I think you mentioned in last post ManagedThreadId is ok to identify -- "ManagedThreadId is fine for identifying threads within .NET"? regards, George
Hi George, I found no easy way to relate ManagedThreadID inside a .NET app to the Thread IDs listed by kernel-level tools such as Task Manager, SystemInfo, etc. That makes it hard to observe multi-threading behavior unless you build a lot of code into the app itself. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
Hi George, I found no easy way to relate ManagedThreadID inside a .NET app to the Thread IDs listed by kernel-level tools such as Task Manager, SystemInfo, etc. That makes it hard to observe multi-threading behavior unless you build a lot of code into the app itself. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
Thanks Luc, -------------------- As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least. What you can do is catch the managed thread ID when the thread gets created, attach a thread name to it (using a Hashtable/Dictionary), then keep track of your threads by asking them their ID, and look up the thread name you assigned earlier. But that is a rather clumsy workaround for a lernel shortcoming. -------------------- So, you think the same is the same in TaskManager and in the .Net App -- even if the ID are not the same? And you use name to link the relationship between them? :-) regards, George
-
Thanks Luc, -------------------- As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least. What you can do is catch the managed thread ID when the thread gets created, attach a thread name to it (using a Hashtable/Dictionary), then keep track of your threads by asking them their ID, and look up the thread name you assigned earlier. But that is a rather clumsy workaround for a lernel shortcoming. -------------------- So, you think the same is the same in TaskManager and in the .Net App -- even if the ID are not the same? And you use name to link the relationship between them? :-) regards, George
Hi George, no 1. I have no way to link managedThreadID (inside app) to kernel thread ID (tools outside app). 2. I use names to log threads, not IDs, to get a human readable log. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
Hi George, no 1. I have no way to link managedThreadID (inside app) to kernel thread ID (tools outside app). 2. I use names to log threads, not IDs, to get a human readable log. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
Thanks Luc! Anyway, using ManagedThreadId is enough for my requirement, right? (I quote my requirement again here) -------------------- My application is pure C# application, and I want to dump thread ID to detect the behavior of each thread, so that I can find deadlock/re-entrance/how many times a thread enters a specific method, something like this. After reading document, I am confused whether I can use ManagedThreadId property, my concern is for example, whether two threads will map to the same ManagedThreadId, so that the monitor is not accurate to serve my purpose. -------------------- regards, George
-
Thanks Luc! Anyway, using ManagedThreadId is enough for my requirement, right? (I quote my requirement again here) -------------------- My application is pure C# application, and I want to dump thread ID to detect the behavior of each thread, so that I can find deadlock/re-entrance/how many times a thread enters a specific method, something like this. After reading document, I am confused whether I can use ManagedThreadId property, my concern is for example, whether two threads will map to the same ManagedThreadId, so that the monitor is not accurate to serve my purpose. -------------------- regards, George
Hi George yes and different Threads will have different ManagedThreadId. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
Hi George yes and different Threads will have different ManagedThreadId. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
Thanks Luc, Question answered. Always happy to learn from you. :-) regards, George
-
Hi George, 1. no 2. no there is no link between managed threads and kernel threads. managed threads are logical things, kernel threads are physical things. even if it seems there is a one-to-one correspondence, .NET does not promise that; in fact they claim multiple managed threads could be executed by a smaller number of kernel thread. As a consequence, there is simply NO WAY to identify your threads; not by name (Windows does not know about thread names), and not easily by thread IDs, they are confusing at the least. What you can do is catch the managed thread ID when the thread gets created, attach a thread name to it (using a Hashtable/Dictionary), then keep track of your threads by asking them their ID, and look up the thread name you assigned earlier. But that is a rather clumsy workaround for a lernel shortcoming. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
Hi Luc, Sorry for interruption again. I am thinking your thread ID and name matching solution. My concern is if you use thread pool to execute a task a couple of times, CLR may choose different thread to execute, which have different thread ID. How do you match in this situation -- to find thread name by thread ID? :-) regards, George
-
Thanks Luc, Question answered. Always happy to learn from you. :-) regards, George
-
I have an additional question here, http://www.codeproject.com/script/Forums/View.aspx?fid=1649&msg=2582539[^] regards, George
-
Hi Luc, Sorry for interruption again. I am thinking your thread ID and name matching solution. My concern is if you use thread pool to execute a task a couple of times, CLR may choose different thread to execute, which have different thread ID. How do you match in this situation -- to find thread name by thread ID? :-) regards, George
Hi George, 1. I typically don't use ThreadPool because IMO it does not offer sufficient control. 2. If you were to use reusable threads (as in ThreadPool) you would have to remove the (ID,name) pair from the hashtable/dictionary as soon as the thread is done doing the action with that name. (You would have to lock the dictionary to do this properly!). :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
Hi George, 1. I typically don't use ThreadPool because IMO it does not offer sufficient control. 2. If you were to use reusable threads (as in ThreadPool) you would have to remove the (ID,name) pair from the hashtable/dictionary as soon as the thread is done doing the action with that name. (You would have to lock the dictionary to do this properly!). :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
You are so smart, Luc! regards, George