Laden...

4 Kerne CPU (aufgabe Verteilung von Threads) Aufgabetyp:myHttpWebRequest

Erstellt von userid15621 vor 11 Jahren Letzter Beitrag vor 11 Jahren 3.202 Views
U
userid15621 Themenstarter:in
104 Beiträge seit 2009
vor 11 Jahren
4 Kerne CPU (aufgabe Verteilung von Threads) Aufgabetyp:myHttpWebRequest

HI,

so funktioniert meine Anwendung zur Zeit:


foreach(xxxxx)
{
  Thread newThread =
                        new Thread(new ThreadStart(Analyse.start));
newThread.Start();
}

Somit laufen 10 Threads in einen Kern?

Ich habe aber 4 Kern CPU und möchte gerne die Aufgabe von 10 Threads auf alle Kerne verteilen.

Ist das möglich? Wie gehe ich am besten vor?

C
2.121 Beiträge seit 2010
vor 11 Jahren

Die Verteilung passiert eigentlich vom Betriebssystem aus. Wie kommst du drauf dass alles auf einem Kern läuft?

U
userid15621 Themenstarter:in
104 Beiträge seit 2009
vor 11 Jahren

Ich bin davon ausgegangen.... wie kann ich ersehen auf welchen Kern mein Thread läuft?

1.346 Beiträge seit 2008
vor 11 Jahren

Gar nicht. Der Thread kann in einer Sekunde nacheinander auf jeden CPU Kern gelaufen sein. Das wird komplett von Windows verwaltet

2.760 Beiträge seit 2006
vor 11 Jahren

Das kannst du mittels SetThreadAffinityMask regeln wobei das im Normalfall nicht nötig sein sollte da der Windows Schedular schon gute Arbeit leistet.

Hier ein kleiner Artikel auf codeproject zu dem Thema: Codeproject Artikel über Schedular und Thread-Affinity

C
2.121 Beiträge seit 2010
vor 11 Jahren

Als Programmierer weiß man normalerweise nicht wie viele Kerne ein Zielrechner haben wird. Außerdem ist es nicht damit getan alles gleichmäßig zu verteilen, da man ja nicht weiß was die Kerne sonst noch alles zu tun haben. Da ist man froh wenn das vom Betriebssystem überwacht und passend aufgeteilt wird.

2.760 Beiträge seit 2006
vor 11 Jahren

Die Anzahl der Kerne kann man mittels Environment.ProcessorCount ermitteln. Aber ich stimme chilic zu das man in den meisten Fällen wohl besser fährt wenn man die Verteilung der Threads über die Kerne dem Scheduar überlässt da man keinen Kern exklusiv reservieren kann.

Außerdem verwende lieber den Threadpool als eigene Threads zu erstellen.

W
872 Beiträge seit 2005
vor 11 Jahren

Du koenntest auch Parallel.ForEach benutzen - dann wird die Runtime entsprechend der Anzahl Kerne und dem Verhalten Deiner Applikation steuern, wieviele Tasks parallel laufen.
Parallel.Foreach hat auch Vorteile beim Fehlerverhalten und Tasks sind schneller gestartet als Threads.

16.807 Beiträge seit 2008
vor 11 Jahren

Außerdem verwende lieber den Threadpool als eigene Threads zu erstellen.

Nein, wenn...

Das Thema ist (aktuell) im Bereich Web, weshalb naheliegt, dass es sich eventuell um eine Webanwendung handelt.
Da der IIS jedoch die Requests mit dem ThreadPool abarbeitet sollte dieser niemals direkt von einer Webanwendung verwendet werden; dies würde die Requests/Sekunden-Quote deutlich absenken.

Bei Webanwendungen sollten steht's die direkten Thread-Klasse, besser die Task-Parallel-Library verwendet werden! In diesem Fall definitiv besser die TPL, da jeder Thread-Erstellung direkt mal Speicher allokiert und man hier sehr sehr schnell in eine MemoryException läuft.
Ob man vom System auslesen kann, wie viel Ressourcen in Form von Prozessoren vorhanden sind, kommt ebenfalls auf die Berechtigung der Webanwendung an.

Generell sollte man aber wirklich dem Scheduler vertrauen und dem nich in die Arbeit pfuschen.

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo Abt,

besser die Task-Parallel-Library verwendet werden!

Dann ist man doch (mit dem standardmäßigen TaskScheduler der TPL) gerade wieder bei ThreadPools-Threads und das ist ein Einklang mit jaensens Aussage. Wie ist dann die TPL in Hinsicht auf

Da der IIS jedoch die Requests mit dem ThreadPool abarbeitet... einzuordnen?

Hallo HL2002,

wie kann ich ersehen auf welchen Kern mein Thread läuft?

mit einem Profiler der das unterstützt, z.B. der VS-eigene Concurrency Profiler.

Da du im Titel "HttpWebRequest" erwähnst, so ist es bei so einer Aufgabe am besten die asynchronen Vorgänge zu verwenden, da somit gar keine CPU-Threads mit Warten verbringen müssen, sondern sobald die Response da ist ein IO-Abschlussthreads verwendet wird, der dann die weitere Verarbeitung erledigt.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

16.807 Beiträge seit 2008
vor 11 Jahren

Ja, das hab ich unterschlagen. Der Standard-Scheduler ist der Thread-Pool und der ist kontraproduktiv; jedoch sollte mit dem IIS8 auch hier eine virtuelle Trennung stattfinden, sodass auch der "normale" Thread-Pool (wieder) verwendet werden kann. Aber das weiß ich nicht genau, da ich mich damit noch nicht beschäftigen konnte.

Oder eben einen eigenen Scheduler; glaub in der MSDN gabs dazu nen Beispiel.