Warum bringt ein Thread Pool was?



  • Das Konzept eines Thread Pools ist mir klar. Dort sind Thread drin, die hängen an irgendnem lock fest, bis es einen neuen Task gibt. Das erspart es, neue Threads zu spawnen, das heißt, eine Kernel-Funktion aufrufen, einen call stack anzulegen, den Thread mit dem aktuellen Prozess zu assoziieren, etc.

    Die spannende Frage wäre, was hindert eigentlich ein OS daran, die Threads eines Prozesses automatisch genauso zu recyclen? Der Aufruf CreateThread() könnte schlichtweg einen arbeitslosen Thread wieder zum Leben erwecken, völlig transparent für das Programm. Warum muss man sich darum selber kümmern?



  • Optimizer schrieb:

    Warum muss man sich darum selber kümmern?

    Weil das OS nur fürs Grobe da ist. Wieso sollte ein Betriebssystem n Threads auf Verdacht schlummern lassen, die sowieso keiner braucht? Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.



  • OSDesignAnalyzer schrieb:

    Optimizer schrieb:

    Warum muss man sich darum selber kümmern?

    Weil das OS nur fürs Grobe da ist. Wieso sollte ein Betriebssystem n Threads auf Verdacht schlummern lassen, die sowieso keiner braucht? Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.

    Wird passieren. Damit .NET-Anwendungen regelmäßig schneller sind als native Anwendungen. Um C++ abzuwürgen. Um freie Software zu dämpfen.



  • volkard schrieb:

    OSDesignAnalyzer schrieb:

    Optimizer schrieb:

    Warum muss man sich darum selber kümmern?

    Weil das OS nur fürs Grobe da ist. Wieso sollte ein Betriebssystem n Threads auf Verdacht schlummern lassen, die sowieso keiner braucht? Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.

    Wird passieren. Damit .NET-Anwendungen regelmäßig schneller sind als native Anwendungen. Um C++ abzuwürgen. Um freie Software zu dämpfen.

    Ein Verschwörungstheoretiker, Juchu!



  • Janjan schrieb:

    Ein Verschwörungstheoretiker, Juchu!

    Wenn man die kontinuierliche Steigerung der Hardwareanforderungen von Windows betrachtet, nicht die der Anwendungen, sondern die des OS selbst, würde ich nicht an eine Verschwörungstheorie denken, sondern an das Prinzip "Viel hilft viel", d.h. verkauft sich gut. 🙄



  • volkard schrieb:

    OSDesignAnalyzer schrieb:

    Optimizer schrieb:

    Warum muss man sich darum selber kümmern?

    Weil das OS nur fürs Grobe da ist. Wieso sollte ein Betriebssystem n Threads auf Verdacht schlummern lassen, die sowieso keiner braucht? Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.

    Wird passieren. Damit .NET-Anwendungen regelmäßig schneller sind als native Anwendungen. Um C++ abzuwürgen. Um freie Software zu dämpfen.

    Warum sollten die nur für .NET-Anwendungen da sein?



  • Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.

    Du bist sicher ein besserer OS-Designer als Microsoft, oder? 😉
    Windows 7 ist gut, egal was ihr Hater dazu ablasst. 🙂



  • Baba Yaga schrieb:

    Janjan schrieb:

    Ein Verschwörungstheoretiker, Juchu!

    Wenn man die kontinuierliche Steigerung der Hardwareanforderungen von Windows betrachtet, nicht die der Anwendungen, sondern die des OS selbst, würde ich nicht an eine Verschwörungstheorie denken, sondern an das Prinzip "Viel hilft viel", d.h. verkauft sich gut. 🙄

    nun ja also das hat doch eher was mit den grafischen anforderungen zu tun. nachdem aber die syscalls fast immer gleich bleiben und nur minimal verändert/ergänzt werden sollte sich am kernel code nicht viel ändern. das es immer noch bloatware ist, steht auf einem anderen blatt, das aber nicht erst seit windows 7 so.

    und natürlich gibt es diese "geheime" vereinbarung zwischen den system herstellern und software herstellern, wobei man es eher anders sehen muß, die system hersteller bringen ein neues system auf den markt und die software hersteller versuchen das dann auszureitzen 😉

    lg lolo



  • Optimizer schrieb:

    Das Konzept eines Thread Pools ist mir klar. Dort sind Thread drin, die hängen an irgendnem lock fest, bis es einen neuen Task gibt. Das erspart es, neue Threads zu spawnen, das heißt, eine Kernel-Funktion aufrufen, einen call stack anzulegen, den Thread mit dem aktuellen Prozess zu assoziieren, etc.

    die kunst besteht eher darin einen fuer die anwendung spezialisierten job-manager fuer den thread pool zu schreiben, ansonsten skaliert sowas sehr sehr schlecht.

    Die spannende Frage wäre, was hindert eigentlich ein OS daran, die Threads eines Prozesses automatisch genauso zu recyclen? Der Aufruf CreateThread() könnte schlichtweg einen arbeitslosen Thread wieder zum Leben erwecken, völlig transparent für das Programm. Warum muss man sich darum selber kümmern?

    ich glaube BeOS hatte sowas verbaut, oder? deswegen gab es damals als minimal hardware dual-socket systeme afaik.

    ansonsten sollte openMP genau das machen, als das war wohl urspruenglich so gedacht.



  • das os hat doch nix mit thread pools am hut. sie stellt der anwendung eine möglichst gute (universelle (dadurch auch aufgeblähte)) api zur verfügung. wenn ich mich richtig erinnere, so bekommen die malloc() implementationen auch einfach eine page und sind nicht slab-allocator basiert, denn dafür ist wieder die user-level api zuständig. also hat jeder so seine aufgabe. wären solche sachen im os eingebaut, könnte man den algo nicht im user-level switchen, was für einen guten programmierer ein nachteil wäre.

    lg lolo



  • noobLolo schrieb:

    wären solche sachen im os eingebaut, könnte man den algo nicht im user-level switchen, was für einen guten programmierer ein nachteil wäre.

    das stimmt nur bedingt.
    1. wenn mehr als nur ein program laeuft, waere es die sache vom OS und nicht vom programmierer von nur einer applikation den pool zu managen.
    auf einer konsole oder einem system was dediziert dafuer aufgesetzt ist performant nur ein program laufen zu lassen (bzw ein spezifisches program packet z.b. webserver), waere es dann natuerlich von nachteil.
    2. "gute programmierer" wuerden dann fiber und nicht threads nutzen.
    3. wenn man sich auf programmierer verlassen koennte, wuerde der OS scheduler nicht budget, sondern prioritaetsbasiert arbeiten.

    ´´´´ schrieb:

    volkard schrieb:

    OSDesignAnalyzer schrieb:

    Optimizer schrieb:

    Warum muss man sich darum selber kümmern?

    Weil das OS nur fürs Grobe da ist. Wieso sollte ein Betriebssystem n Threads auf Verdacht schlummern lassen, die sowieso keiner braucht? Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.

    Wird passieren. Damit .NET-Anwendungen regelmäßig schneller sind als native Anwendungen. Um C++ abzuwürgen. Um freie Software zu dämpfen.

    Warum sollten die nur für .NET-Anwendungen da sein?

    naja, wenn die leute nichtmal mit memory management klarkommen und froh sind wenn jemand fuer sie die arbeit suboptimal verrichtet (natuerlich unter guten marketing versprechungen), wie sollen die leute dann mit threads klarkommen? einfach soviele threads wie cores vorhanden sind zu starten wird in sovielen faellen vorteile brigen wie auch es faelle mit nachteiligem verhalten gibt. und vorausschauden skalieren wird sowas sicherlich nicht.

    "Superior Visual Basic Runtime Thread scheduller" ftw 🙂



  • Hmmm, so völlig überzeugende Argumente waren jetzt imho nicht dabei, wieso man nicht transparent für das Programm den Overhead vom OS aus reduzieren kann. Ich sehe gewissermaßen den Erziehungseffekt: die Lösung wäre in den meisten Fällen wohl suboptimal (da nicht anwendungsspezifisch). Das muss noch nicht mal schlimm sein, könnte aber dafür sorgen, dass die Leute sich nicht mehr nach einer optimalen Lösung umsehen, selbst wenn es Sinn macht.

    Ich habe jetzt btw. ganz gute Erfahrungen mit diesem Pool gemacht:
    http://threadpool.sourceforge.net/index.html
    Man kann eigene scheduling policies einklinken, benutzt boost threads, steht unter der Boost license.

    Hat bei mir den Speedup auf meinem dual core von 1.68 auf 1.92 verbessert (gegenüber spawnen und joinen), was ziemlich gut ist, da ich viele kleine Fitzel-Tasks habe, so dass der Overhead durch das multi-threading signifikant wird.

    OpenMP ist in meinem Fall ungeeignet gewesen, ich habe zwar an sich eine schöne Schleife zum parallelisieren, muss die Ausführung aber unter bestimmten Umständen abbrechen. Das ist schon ziemlich hässlich gewesen, man muss mit OMP-Konstrukten die Schleife nachbauen, habe mich selber um das load-balancing usw. kümmern müssen, also praktisch keine Vereinfachung mehr durch OpenMP gehabt. Dafür war es ziemlich hässlich, im Vergleich zu meiner jetzigen Lösung mit boost threads.



  • rapso schrieb:

    das stimmt nur bedingt.
    (...)
    2. "gute programmierer" wuerden dann fiber und nicht threads nutzen.

    wieso? damit sie mehr selber programmieren müssen und mehr fehler machen können?

    3. wenn man sich auf programmierer verlassen koennte, wuerde der OS scheduler nicht budget, sondern prioritaetsbasiert arbeiten.

    windows schedulliert prioritaetsbasiert.



  • OSDesignAnalyzer schrieb:

    Optimizer schrieb:

    Warum muss man sich darum selber kümmern?

    Weil das OS nur fürs Grobe da ist. Wieso sollte ein Betriebssystem n Threads auf Verdacht schlummern lassen, die sowieso keiner braucht? Aber vielleicht kommt M$ bei Windows 8 mal auf die hirnrissige Idee, 16384 suspendierte Threads beim Start des Systems für Anwendungen bereitzuhalten. Zuzutrauen wäre es ihnen ja.

    Im verlinkten Webinar von

    http://www.c-plusplus.net/forum/viewtopic-var-p-is-1887967.html

    wird dazu was gesagt, wie MS sich das künftig vorstellt.



  • hustbaer schrieb:

    rapso schrieb:

    das stimmt nur bedingt.
    (...)
    2. "gute programmierer" wuerden dann fiber und nicht threads nutzen.

    wieso? damit sie mehr selber programmieren müssen und mehr fehler machen können?

    ja, deine weisheit hat eindeutig zugeschlagen.

    3. wenn man sich auf programmierer verlassen koennte, wuerde der OS scheduler nicht budget, sondern prioritaetsbasiert arbeiten.

    windows schedulliert prioritaetsbasiert.

    weil priority als parameter/funktionsname steht? klar.



  • rapso schrieb:

    hustbaer schrieb:

    rapso schrieb:

    das stimmt nur bedingt.
    (...)
    2. "gute programmierer" wuerden dann fiber und nicht threads nutzen.

    wieso? damit sie mehr selber programmieren müssen und mehr fehler machen können?

    ja, deine weisheit hat eindeutig zugeschlagen.

    OK, sorry. da hab ich mal wieder zu wenig/zu schnell gelesen und deine aussage komplett falsch verstanden.

    3. wenn man sich auf programmierer verlassen koennte, wuerde der OS scheduler nicht budget, sondern prioritaetsbasiert arbeiten.

    windows schedulliert prioritaetsbasiert.

    weil priority als parameter/funktionsname steht? klar.

    nein. weil microsoft sagt dass es so ist.

    http://msdn.microsoft.com/en-us/library/ms685100(VS.85).aspx
    2. Absatz:

    The system treats all threads with the same priority as equal.The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority. If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread (without allowing it to finish using its time slice), and assigns a full time slice to the higher-priority thread. For more information, see Context Switches.

    das ist für mich die definition von "prioritaetsbasiert". oder besser: round-robin.



  • hustbaer schrieb:

    http://msdn.microsoft.com/en-us/library/ms685100(VS.85).aspx
    2. Absatz:

    The system treats all threads with the same priority as equal.The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority. If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread (without allowing it to finish using its time slice), and assigns a full time slice to the higher-priority thread. For more information, see Context Switches.

    das ist für mich die definition von "prioritaetsbasiert". oder besser: round-robin.

    round-robin hat nicht wirklich was mit prioritaet zu tun.
    aber ja, die definition stimmt soweit, jedoch kannst du soviele "higher-priority" programme starten wie du cores hast (also programme die ihren thread auf high priority setzen), und dennoch werden die anderen "normal priority" programme rechenzeit abbekommen.
    Threads mit hoeherer prioritaet bekommen schon vorzug vor anderen, aber nicht 100% der zeit gegenueber niedriger prioritisierten threads, was eher budgeting statt prioritisierung ist, imo.



  • Also mit budgeting hat das nun garnix zu tun.
    Es wird jedesmal eine frische Zeitscheibe angefangen, ganz egal wie viel von der letzten Zeitscheibe ein Thread verbraucht hat.

    Windows schraubt dann noch dynamisch an den Prioritäten, aber das ist auch nur "Tuning" um bestimmten Programmen (IO bound) den Vorzug zu geben, bzw. zumindest den Nachteil wieder gut zu machen den sie ohne derartiges "Tuning" hätten, jedesmal wenn sie einen IO absetzen (nämlich dass sie sofort den ganzen Rest ihrer Zeitscheibe verlieren, und wieder eine ganze Runde warten müssen).


Log in to reply