Seite 2 von 4
Re: Thread Pool
Verfasst: 28.02.2012 13:52
von bobobo
Christian+ hat geschrieben:
[um die Verteilung der Threads auf einzelne Prozessorkerne]..kümmert sich ja das Betriebssystem ...
tut es das ? imho gilt das für kernelthreads und nicht für userthreads.
pb erzeugt kernelthreads ?
Re: Thread Pool
Verfasst: 28.02.2012 14:04
von Christian+
Ja klar zumindest auf Windows denke aber auch auf Linux und Mac da heute jeder Rechner 2 - 8 Kerne hat wäre es anders auch etwas ungünstig.
Mit Userthreads gäbe es ja keine Möglichkeit ein Programm zu schrieben das so einen Prozessor vernünftig ausnutzt.
Re: Thread Pool
Verfasst: 28.02.2012 14:16
von ts-soft
Bei Kernelthreads, die PB nicht erzeugt, kann man bestimmen welcher Core genutzt werden soll,
bei Userthreads wird dies vom OS bestimmt. D.H. aber nicht, das ein Process mit mehreren Threads
nicht auf mehrere Cores verteilt wird!
Re: Thread Pool
Verfasst: 28.02.2012 15:09
von Christian+
Ich weiß ja nicht wie du das definiert bzw. was deine Quelle ist aber meines Wissens werden Kernelthreads von Betriebssystem angeboten und verwaltet und haben dadurch den Vorteil das diese vom Betriebssystem auch verschiedenen Rechenkernen der CPU zugewiesen werden können. Während Userthreads die Programmteile verzahnt/parallel ablaufen lassen von beliebigen Bibliotheken (auch z.B. des Betriebssystem) bereitgestellt werden können. Da diese aber innerhalb eines einzigen Prozess/Kernelthread laufen und nicht durch die Betriebssystem interne Verwaltung verwaltet werden laufen sie auch immer auf dem Rechenkern auf dem der Prozess/Thread zu dem sie gehören läuft. In der Wikipedia steht es ähnlich (
http://de.wikipedia.org/wiki/User_Thread).
Die angesprochene Möglichkeit einen Thread einem bestimmten Kern zuzuweisen ist meines wissen nicht so einfach und hat auch normalerweise keinen Sinn. Was bringt es wenn dann 50 Threads auf einem Laufen und andere 7 Kerne nichts zu tun haben nur weil jemand meinte es besser zu wissen wie das OS?
Re: Thread Pool
Verfasst: 28.02.2012 15:21
von WPö
Hattest recht, Christian. Debugger abgeschaltet, schon sank bei 50x500.000.001 Schleifendurchläufe die Ausführungszeit auf 49,2s und 96,2s. Die Kernausnutzung war 100%/100% (erwartet) und 85%/25% (immer noch zu viel Last auf 2. Kern). Egal.
Davon abgesehen, finde ich meinen Text überhaupt nicht schwer zu lesen. Dein Text hingegen bereitet mir Mühe, da Deine Kommataste kaputt zu sein scheint. Bitte reparieren!
Gruß - WPö
Re: Thread Pool
Verfasst: 28.02.2012 15:22
von NicTheQuick
Und wie man in Wiki auch lesen kann, werden dort Userthreads auch Fiber unter Windows genannt und unter Linux werden Userthreads von LinuxThreads oder GNU Porttable Threads verwaltet. Im Umkehrschluss kann man also sagen, dass PB echte Threads nutzt, die im Falle eines Multicore-Prozessors auch echt parallel laufen und nicht nur nebenläufig.
Kiffi hat geschrieben:WPö hat geschrieben:Nebenläufigkeit
man kann es auch übertreiben...
Grüße ... Kiffi
Was willst du uns damit sagen?
Re: Thread Pool
Verfasst: 28.02.2012 16:09
von Christian+
@NicTheQuick
Deine Aussage verstehe ich jetzt nicht ganz. Ok Userthreads wären Fiber oder GNU Portable Threads aber Linux hat auch Möglichkeiten Threads wie die richtigen Threads auf Windows die Kernelthreads sind zu Verfügung zu stellen. Das ist auch der Unterschied Fiber und GNU Porttable Threads werden verwendet um die dem Kernelthread/Prozess zustehenden Ressourcen voll auszunutzen und führen den Code vereinfacht gesagt abwechselnd aus als wäre es parallel während Threads auf Windows wirklich parallel also zeitgleich auf mehreren Kernen laufen können. So ist es doch auch im Wiki sowohl deutsches wie englisches weswegen ich jetzt nicht verstehe wem du recht geben wolltest.
Klar ist auf jeden Fall PB nutzt mehrere Kerne gleichzeitig es muss also dem Betriebssystem klar sein welche Threads es gibt und dieses ihnen Prozessor und Rechenzeit zuweisen.
Daraus folgt aus meiner Sicht das es Kernelthreads sind da OS verwaltet und keine Userthreads die mit eigenem Scheduling innerhalb eines Kernelthreads/Prozesslaufen und so nur Abwechselnd drankommen nicht Zeitgleich auf mehreren Kernen.
Re: Thread Pool
Verfasst: 28.02.2012 16:24
von Nino
@Christian+:
Herzlichen Dank für die Erklärungen, die Du in den Code eingefügt hast!
Vielleicht hast Du Zeit und Lust, noch ein anderes Beispiel zu posten?
Viele Grüße, Nino
PS: Leude, wie diese Threads nu heißen is doch wurscht, Hauptsach et löppt.
Re: Thread Pool
Verfasst: 28.02.2012 16:32
von bobobo
Christian+ hat geschrieben:@NicTheQuick
Deine Aussage verstehe ich jetzt nicht ganz. .
Ist doch ganz einfach.
Nic meint, wenn Du Dein Auto Porsche nennst fährt es 280.
-----------
folgender Code erzeugt (im Taskmanager schön zu sehen) bei
zwei Prozzen als Kompilat (threadsafe OFF) einen schön einseitig
hängenden 2-threadigen Prozess.
Code: Alles auswählen
Global quitit,runner,e,w
Procedure arbeiter(null)
Repeat
AddGadgetItem(e,0,"arbeitet"+Str(quitit)+" "+Str(ElapsedMilliseconds()))
If CountGadgetItems(e)>5
RemoveGadgetItem(e,5)
EndIf
Until quitit
runner=0
EndProcedure
w=OpenWindow(#PB_Any,0,0,200,200,"Arbeiter")
e=EditorGadget(#PB_Any,0,0,200,200)
runner=1
CreateThread(@arbeiter(),#Null)
MessageRequester("Chef","Pennt")
quitit=1
While runner
AddGadgetItem(e,0,"zumachen"+Str(runner))
If CountGadgetItems(e)>5
RemoveGadgetItem(e,5)
EndIf
Delay(10)
While WindowEvent():Wend ;hab ja sonst keine eventschleife
Wend
MessageRequester("Schicht","im Schacht")
Re: Thread Pool
Verfasst: 28.02.2012 16:37
von STARGÅTE
Hallo Christian+,
in meinen Augen ist dein Vorteil den du anbietest, nämlich das zu Anfang immer eine feste Anzahl von Threads erstellst (CreateThreadPool) und danach die aufgaben zuweißt, dadurch zunichte gemacht, dass man aktuell immer gezwungen wird, den Pool wieder zu schleißen um eine Synchronisation zu erhalten.
Meiner Meinung nach wäre es sinnvoller, den Pool wie ein PB objekt zu behandeln, und die Pool einmal zu erstellen und dann lieber auch die Funktion WaitThreadPool() anzubieten, welche einfach nur wartet bis alle Threads fertig sind, den Pool+Threads aber nicht löscht, damit man danach wieder neue Aufgaben einbinden kann.
Außerdem ist Run() kein guter Funktionsname: dann lieber AddThreadPoolThread() oder AddThreadPoolTask() oder nur ThreadPoolTask() ...