[C#] ID van Thread

[Verwijderd]

Wat ik wil is het huidige Thread ID weer geven, dit lukt me alleen niet..

ook de volgende code geeft NIET het goede ID van het Thread:


i=Thread.CurrentThread.ManagedThreadId;
Process MyProc = Process.GetCurrentProcess();
MyProc.Threads[i].Id // geeft verkeerde Thread iD!!!

de fout in bovenstaande code is makkelijk te traceren namelijk als de current thread priotiy naar bv Highest wordt gezet en je vraagt de priotiteit op van MyProc.Threads[i] dan geeft deze normaal terug, terwijl op een andere waarde voor i, wel prioriteit is verandert... Wie ow wie weet OF i te vinden, OF ThreadID (beide ut zelfde )

[Viper®]

Thread.CurrentTHread.GetHashCode() ?

[Verwijderd]

Viper® schreef op woensdag 28 maart 2007 @ 15:15:
Thread.CurrentTHread.GetHashCode() ?

Geeft bij mij exact hetzelfde terug als ManagedID??? dus geen goede waarde

[mulder]

Je gebruikt de Id als Index?

[Verwijderd]

Don Facundo schreef op woensdag 28 maart 2007 @ 15:37:
Je gebruikt de Id als Index?

Neej daar doe ik niets mee...

Ik wil gewoon het thread ID opvragen? Wat je ook vanuit een ander process "ziet" zeg maar.

edit:

je bedoelt in het voorbeeld? idd daar zou ik het gebruiken als index voor de threads in het process

edit2:
nog even een voorbeeldje:

Thread reports his name: Thread1Name ID: 4 Priority: BelowNormal
Debug: hash=4 ManagedThreadId=4
i=0 3044 i's PriorityLevel: AboveNormal
i=1 3792 i's PriorityLevel: Normal
i=2 2692 i's PriorityLevel: Highest
i=3 3148 i's PriorityLevel: Normal
i=4 2488 i's PriorityLevel: Normal
i=5 3904 i's PriorityLevel: Normal
i=6 1560 i's PriorityLevel: Normal
.........
i=19 2380 i's PriorityLevel: Normal
i=20 3752 i's PriorityLevel: BelowNormal


Zowel GetHash als managedThreadID = 4 current ThreadPriority is naar BelowNormal gezet alleen op plekje 4 staat de priority level normal (das dus niet het goeie thread in de process list)
Echter op i=20 staat het juiste thread (id=3752, op index 20)


Code:

Process MyProc = Process.GetCurrentProcess();
Thread ThisThread = Thread.CurrentThread;

LogThis("Thread reports his name: " + MyName + " ID: " + Thread.CurrentThread.GetHashCode() + " Priority: " + Thread.CurrentThread.Priority);
LogThis("Debug: hash" + Thread.CurrentThread.GetHashCode() + " ManagedThreadId " + Thread.CurrentThread.ManagedThreadId + " " + Thread.CurrentThread);
for(int i=0;i<MyProc.Threads.Count;i++)
{
LogThis("i=" + i + " " + MyProc.Threads[i].Id + " i's PriorityLevel: " + MyProc.Threads[i].PriorityLevel );
}

[ Voor 88% gewijzigd door Verwijderd op 28-03-2007 15:54 ]

[whoami]

Dit is geen architectuur
-> PRG

[whoami]

Je gebruikt wel de ThreadId als index:
^Copy / Paste uit je TS:

code:

i=Thread.CurrentThread.ManagedThreadId;
Process MyProc = Process.GetCurrentProcess();
MyProc.Threads[i].Id // geeft verkeerde Thread iD!!!

Threads[i] .... 'nuff said ?
Je threads worden toch niet op volgorde / basis van het ManagedThreadId opgeslagen in de Threads collection...

[Verwijderd]

whoami schreef op woensdag 28 maart 2007 @ 16:07:
Je gebruikt wel de ThreadId als index:
^Copy / Paste uit je TS:
[code]i=Thread.CurrentThread.ManagedThreadId;
Process MyProc = Process.GetCurrentProcess();
MyProc.Threads.Id // geeft verkeerde Thread iD!!!
Threads[i] .... 'nuff said ?
Je threads worden toch niet op volgorde / basis van het ManagedThreadId opgeslagen in de Threads collection...

Nee zucht oke, je hebt gelijk, hoe moet het dan wel... Dit is niet echt opbouwend!!

[Ricvdp]

Verwijderd schreef op woensdag 28 maart 2007 @ 18:33:
[...]


Nee zucht oke, je hebt gelijk, hoe moet het dan wel... Dit is niet echt opbouwend!!

offtopic:
Nu wil ik niet veel zeggen, maar je loopt de moderator van dit forum te beschuldigen dat zijn commentaar niet opbouwend is. Dat is het echter wel. Ik zie dat je geen nieuw lid bent, dit verbaast me, ik zou verwachten dat je inmiddels wel zou weten hoe het er op GoT aan toe gaat.
Whoami geeft de aard van het probleem aan, zodat jij weet wat het probleem is en het op kan lossen. We zitten hier niet om alles voor te kauwen en zo leer je er ook nog eens wat van.
Ik beschuldig je nergens van maar raad je aan de FAQs nogeens te lezen. Aan je posts te zijn ben je een tijdje weggeweest, en sinds 2002 is er veel veranderd op GoT.

Ik kan het nu wel voorkauwen maar kijk maar naar de reactie van whoami.

[Verwijderd]

Ricvdp schreef op woensdag 28 maart 2007 @ 18:48:
[...]

offtopic:
Nu wil ik niet veel zeggen, maar je loopt de moderator van dit forum te beschuldigen dat zijn commentaar niet opbouwend is. Dat is het echter wel. Ik zie dat je geen nieuw lid bent, dit verbaast me, ik zou verwachten dat je inmiddels wel zou weten hoe het er op GoT aan toe gaat.
Whoami geeft de aard van het probleem aan, zodat jij weet wat het probleem is en het op kan lossen. We zitten hier niet om alles voor te kauwen en zo leer je er ook nog eens wat van.
Ik beschuldig je nergens van maar raad je aan de FAQs nogeens te lezen. Aan je posts te zijn ben je een tijdje weggeweest, en sinds 2002 is er veel veranderd op GoT.

Ik kan het nu wel voorkauwen maar kijk maar naar de reactie van whoami.

Jah dat snap ik... maar ik ben er al een hele dag mee bezig en ik kom er niet uit? Volgens mij zit ik verkeerd te denken ofzo?

[mulder]

Verwijderd schreef op woensdag 28 maart 2007 @ 18:51:
[...]


Jah dat snap ik... maar ik ben er al een hele dag mee bezig en ik kom er niet uit? Volgens mij zit ik verkeerd te denken ofzo?

Je moet ook even tot 10 tellen en rustig kijken wat er nu fout gaat. De code die je de eerste keer gepost hebt zal niet werken, je gebruikt daar de Id als de index, ben je je daar nu bewust van? Dat lijkt namelijk wel in de latere posts, maar de code daar gebruik je anders. Dus welke code werkt nu precies niet.

[RobLemmens]

Die thread id wat je opvraagt is niet dezelfde als die je van buitenaf ziet. ManagedThreadId keert de id van de .net runtime thread en niet die van windows. Deze id is niet te gebruiken als index in de threadlist van je proces. GetCurrentProcess keert info over het huidige process en de thread ids die je daar vind zijn native thread ids en hebben een andere waarde dan die van .net. Deze threads worden door de runtime gebruikt om de .net code uit te voeren en voor bv de garbage collector.

[Verwijderd]

Don Facundo schreef op woensdag 28 maart 2007 @ 19:20:
[...]
Je moet ook even tot 10 tellen en rustig kijken wat er nu fout gaat. De code die je de eerste keer gepost hebt zal niet werken, je gebruikt daar de Id als de index, ben je je daar nu bewust van? Dat lijkt namelijk wel in de latere posts, maar de code daar gebruik je anders. Dus welke code werkt nu precies niet.

Jah sorry het gaat dus om de code die ik in de latere post heb gezet..

RobLemmens schreef op woensdag 28 maart 2007 @ 19:30:
Die thread id wat je opvraagt is niet dezelfde als die je van buitenaf ziet. ManagedThreadId keert de id van de .net runtime thread en niet die van windows. Deze id is niet te gebruiken als index in de threadlist van je proces. GetCurrentProcess keert info over het huidige process en de thread ids die je daar vind zijn native thread ids en hebben een andere waarde dan die van .net. Deze threads worden door de runtime gebruikt om de .net code uit te voeren en voor bv de garbage collector.

Dat heb ik dus ook door, maar hoe vind ik van CurrentThread het Native ThreadID???

[MTWZZ]

Via AppDomain:

C#:

Console.WriteLine("ThreadID: " + AppDomain.GetCurrentThreadId());

[Verwijderd]

MTWZZ schreef op donderdag 29 maart 2007 @ 09:01:
Via AppDomain:

C#:

Console.WriteLine("ThreadID: " + AppDomain.GetCurrentThreadId());

Danku! das nou bruikbaar!
ik vond heel toevallig zelf net het volgende:

C#:

[DllImport("Kernel32")]
private static extern int GetCurrentThreadId();

stom eigenlijk want ik had ook direct aan een api call kunnen denken...
AppDomain.GetCurrentThreadId() geeft bij mij wel een melding dat deze deprecated is... :

Warning 1 'System.AppDomain.GetCurrentThreadId()' is obsolete: 'AppDomain.GetCurrentThreadId has been deprecated because it does not provide a stable Id when managed threads are running on fibers (aka lightweight threads). To get a stable identifier for a managed thread, use the ManagedThreadId property on Thread. http://go.microsoft.com/fwlink/?linkid=14202'

Welke zal ik gaan gebruiken AppDomain.GetCurrentThreadId is zeker Managed?? terwijl een API call niet per definitie managed is?

[MTWZZ]

GetCurrentThreadId mag blijkbaar niet gebruikt worden vanwege het volgende. De CLR kan meerdere logische threads (de threads die je in C# maakt) runnen op 1 fysieke thread (die windows maakt). Dit is niet altijd zo maar wel iets waar je rekening mee moet houden als je veel threads maakt. In het geval dat er dus meerdere logische threads op 1 fysieke thread draaien geeft GetCurrentThreadId() voor die logische threads hetzelfde fysieke ThreadID terug.

[Verwijderd]

MTWZZ schreef op donderdag 29 maart 2007 @ 09:59:
GetCurrentThreadId mag blijkbaar niet gebruikt worden vanwege het volgende. De CLR kan meerdere logische threads (de threads die je in C# maakt) runnen op 1 fysieke thread (die windows maakt). Dit is niet altijd zo maar wel iets waar je rekening mee moet houden als je veel threads maakt. In het geval dat er dus meerdere logische threads op 1 fysieke thread draaien geeft GetCurrentThreadId() voor die logische threads hetzelfde fysieke ThreadID terug.

Ja inderdaad, das toch apart, want ik wil juist dat mijn threads volledig onafhankelijk lopen, maar tot nu toe kloppen de id's die ik krijg met mijn metingen..

[MTWZZ]

De threads lopen ook echt apart hoor. De CLR zorgt er alleen voor dat de fysieke threads efficienter gebruikt worden. Threads zijn relatief duur om te maken en context switching is ook niet goedkoop.
Je kunt eventueel nog zoeken op "fibers" op MSDN

[Verwijderd]

MTWZZ schreef op donderdag 29 maart 2007 @ 11:19:
De threads lopen ook echt apart hoor. De CLR zorgt er alleen voor dat de fysieke threads efficienter gebruikt worden. Threads zijn relatief duur om te maken en context switching is ook niet goedkoop.
Je kunt eventueel nog zoeken op "fibers" op MSDN

Voorlopig lijkt het switchen geen probleem op te leveren... daar lever ik eigenlijk niets in aan performance.. Binnenkort maar eens door de CLR Profiler gooien...

[MTWZZ]

Lees nog even goed wat ik hierboven beschreven heb:

(1) De System.Threading.Thread instanties in jouw .Net applicatie zijn volstrekt van elkaar gescheiden.
(2) De CLR heeft een mechanisme om efficiënt native threads te gebruiken.

(1) geeft je de garantie dat elke thread zijn eigen omgeving heeft analoog aan het gebruik van native threads.

Wat (2) wil zeggen is dat de CLR soms twee of meer System.Threading.Thread instanties op een native thread plaatst omdat dat op dat moment, volgens de CLR, efficiënter is.
Het gevolg hiervan is dat meerdere instanties System.Threading.Thread hetzelfde native thread id hebben. Om er voor te zorgen dat binnen de CLR de threads uit elkaar gehouden kunnen worden is het ManagedThreadId property in het leven geroepen. Deze bevat dus een id wat uniek is binnen de CLR.

Het is echter wel zo dat de CLR bepaalt of dit gebeurt en dat je dat niet van tevoren vast kunt stellen of het ook gaat gebeuren. Feit blijft wel dat je dus niet klakkeloos kunt zeggen dat het id dat je via AppDomain.GetCurrentThreadId() ophaalt ook echt uniek is voor de thread waar vandaan je die call doet.

[Verwijderd]

MTWZZ schreef op vrijdag 30 maart 2007 @ 10:01:
Lees nog even goed wat ik hierboven beschreven heb:

(1) De System.Threading.Thread instanties in jouw .Net applicatie zijn volstrekt van elkaar gescheiden.
(2) De CLR heeft een mechanisme om efficiënt native threads te gebruiken.

(1) geeft je de garantie dat elke thread zijn eigen omgeving heeft analoog aan het gebruik van native threads.

Wat (2) wil zeggen is dat de CLR soms twee of meer System.Threading.Thread instanties op een native thread plaatst omdat dat op dat moment, volgens de CLR, efficiënter is.
Het gevolg hiervan is dat meerdere instanties System.Threading.Thread hetzelfde native thread id hebben. Om er voor te zorgen dat binnen de CLR de threads uit elkaar gehouden kunnen worden is het ManagedThreadId property in het leven geroepen. Deze bevat dus een id wat uniek is binnen de CLR.

Het is echter wel zo dat de CLR bepaalt of dit gebeurt en dat je dat niet van tevoren vast kunt stellen of het ook gaat gebeuren. Feit blijft wel dat je dus niet klakkeloos kunt zeggen dat het id dat je via AppDomain.GetCurrentThreadId() ophaalt ook echt uniek is voor de thread waar vandaan je die call doet.

Dus blijf ik lekker native threads gebruiken

zeker na het lezen van het volgende (mijn threads blijven het hele programma leven dus ik heb geen korte threads):

http://en.wikipedia.org/wiki/Multithreading

Kernel threading also has performance limits. Each time a thread starts, blocks, or exits, the process must switch into kernel mode, then back into user mode. This context switch is fairly quick, but programs that create many short-lived threads can suffer a performance hit. Hybrid threading schemes are available which provide a balance between kernel threads and fibers.

In most cases, the work required to use fibers is not justified, as most modern operating systems provide efficient support for threads.

Gezien ik een pc heb met 1.5 Ghz is het dus absoluut geen probleem... en gelukkig hebben we genoeg resources=D bovendien:

However, the use of blocking system calls in fibers can be problematic. If a fiber performs a system call that blocks, the other fibers in the process are unable to run until the system call returns. A typical example of this problem is when performing I/O: most programs are written to perform I/O synchronously. When an I/O operation is initiated, a system call is made, and does not return until the I/O operation has been completed. In the intervening period, the entire process is "blocked" by the kernel and cannot run, which starves other fibers in the same process from executing.

En dat is iets wat erg belangrijk is in mijn geval.. een redelijk RealTime systeem is het ivm een realtime communicatie bus Hier is gelukkig al een driver voor geschreven ... Dus fibers zijn eigenlijk niet echt super handig meer in mijn geval...

[MTWZZ]

Verwijderd schreef op vrijdag 30 maart 2007 @ 23:16:
Dus blijf ik lekker native threads gebruiken

zeker na het lezen van het volgende (mijn threads blijven het hele programma leven dus ik heb geen korte threads):

Gezien je programma zal de CLR dat ook wel voor je doen.

Gezien ik een pc heb met 1.5 Ghz is het dus absoluut geen probleem... en gelukkig hebben we genoeg resources=D bovendien:

Zeggen dat iets geen probleem is omdat je toch veel resources hebt is IMNSHO complete bullshit.

[Verwijderd]

MTWZZ schreef op zaterdag 31 maart 2007 @ 16:09:
[...]

Zeggen dat iets geen probleem is omdat je toch veel resources hebt is IMNSHO complete bullshit.

opzich kan het niet zo'n kwaad om je proggen af te stemmen op je systeem. m.a.w. als je toch je app enkel draait op een top systeem maakt het niet zo heel veel uit als je prog niet echt geoptimaliseerd is. maar om programmeerfouten door het systeem op te laten vangen met "hij is snel zat" is wel erg makkelijk natuurlijk overigens in dit geval geef ik hem geen ongelijk om geen fibers te gebruiken. snelheidsverschil is minimaal. fibers zijn leuk als je bij ppc progs schrijft.

[ Voor 12% gewijzigd door Verwijderd op 31-03-2007 16:48 ]

[MTWZZ]

Voor zijn applicatie is het inderdaad niet nuttig om fibers te gebruiken. Maar het punt dat ik probeer te maken is dat de .Net CLR zelf fibers kan gebruiken om .Net threads te implementeren.

In het geval dat je een server applicatie maakt die veel clients tegelijkertijd moet kunnen verwerken dan zijn fibers uitstekende dingen om te gebruiken.

[Verwijderd]

MTWZZ schreef op zaterdag 31 maart 2007 @ 17:04:
Voor zijn applicatie is het inderdaad niet nuttig om fibers te gebruiken. Maar het punt dat ik probeer te maken is dat de .Net CLR zelf fibers kan gebruiken om .Net threads te implementeren.

In het geval dat je een server applicatie maakt die veel clients tegelijkertijd moet kunnen verwerken dan zijn fibers uitstekende dingen om te gebruiken.

Gelukkig is het in mijn geval zo, dat bij de start een static aantal threads worden gestart die tot het einde van het programma duren. Dus fibers zijn geen waardevol voordeel voor mijn app! (gezien ik resources genoeg heb)....

Resources daarin tegen als argument om "maar bagger" te programmaeren is iets heel anders natuurlijk. Ik bedoelde: in jou posts zeg je dat threads meer "kosten", maar die kosten zijn natuurlijk niets op een hedendaags systeem!!!

kort door de bocht: Het maakt niet uit of je threads of fibers gebruikt in een een app welke op een pc draait... (mits je geen zeer specifieke eisen stelt).. Wat wel belangrijk is is je API omgang!!!!! Dit is kan bij threads véél voordeliger/makkelijker zijn(zie ook het stuk van Wiki)...

[Korben]

Verwijderd schreef op zaterdag 31 maart 2007 @ 21:16:
[...]
kort door de bocht: Het maakt niet uit of je threads of fibers gebruikt in een een app welke op een pc draait... (mits je geen zeer specifieke eisen stelt).. Wat wel belangrijk is is je API omgang!!!!! Dit is kan bij threads véél voordeliger/makkelijker zijn(zie ook het stuk van Wiki)...

Het maakt wél uit. Als jouw programma om wat voor reden dan ook heel veel korte threads aanmaakt, dan maakt het wel degelijk een verschil in performance of je threads of fibers gebruikt. Het punt is alleen: als je .NET gebruikt hoef je je helemaal geen zorgen te maken over wat er gebruikt wordt, want de CLR regelt dat allemaal voor je. Dat is nou het mooie van .NET (naast vele andere mooie dingen): het is managed.

[Verwijderd]

Korben schreef op zaterdag 31 maart 2007 @ 23:55:
[...]


Het maakt wél uit. Als jouw programma om wat voor reden dan ook heel veel korte threads aanmaakt, dan maakt het wel degelijk een verschil in performance of je threads of fibers gebruikt. Het punt is alleen: als je .NET gebruikt hoef je je helemaal geen zorgen te maken over wat er gebruikt wordt, want de CLR regelt dat allemaal voor je. Dat is nou het mooie van .NET (naast vele andere mooie dingen): het is managed.

Totdat er delen unmanaged code inzitten... (laat dat nou zo wezen).... Bovendien zei ik al dat er enkel een static aantal threads zal draaien tot het eeind van het programma....

Maar goed... dit gaat wel erg offtopic... Native thread id ophalen is gelukt