Thread Pool

[bobobo]

[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 ?

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

[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!

[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?

[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ö

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

Nebenläufigkeit

man kann es auch übertreiben...

Grüße ... Kiffi

Was willst du uns damit sagen?

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

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

[bobobo]

@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")

[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() ...