Bestes OS für Multithreading?

Ok, der Begriff ist jetzt sicher unbeabsichtigt etwas provozierend aber die FRage ist durchaus ernst gemeint. Bei großen, Datenbank gestützten Websites kommt so langsam immer mehr in Mode das sie die COMET Technologie und Ajax als Client Counterpart einsetzen. Ajax erlaubt es bekanntlich nur bestimmte Teile einer Website neu zu laden, anstatt die ganze Seite neu anzufordern. Das dumme ist nur, bisher wurde dafür am Webserver jeweils ein neuer Workerthread gestartet.Die lösung scheinen, nicht blockierende, asyncrone Threads zu sein. Eine Tiefenanalyse eines amerikanischen Programmieres hat jedoch jetzt ergeben das die blockierende und nicht blockierendes threading vom Performanceansatz kaum voneinander differieren, die Performance bleibt also nahezu absolut gleich, obwohl man lange Zeit davon Ausging das nio und async Thread selbstredend besser abschneiden müssten! Ein großer Irrtum wie sich herausstellte. Der Grund dafür ist nicht die aktuelle Hardware, auch nicht Java oder andere Webapplikations-Systeme die Comet oder threaded
HTTP-Streaming nutzen sondern schlicht das OS und dessen Threading Architektur.

Ich gebe zu, ich habe schon von Windows bis Linux/Unix mit Threads gearbeitet aber mit der Frage welches OS z.B bei AMD64 Prozessoren das beste Usermode Threading bietet musste ich mich noch nicht auseinander setzen und leider gibt es erschreckend wenig lesenswertes Material zu genau diesen Thema, das angesichts von allgegenwärtigen Multicore und 64-Bit Systemen, Hyperthreading, Quadcores und demnächst 16 Core Systemen so langsam nicht mehr ganz unwichtig ist wenn es um skalierbare Anwendungen geht die die Hardwareressouren auch nutzen sollen.

Ich meine, es bringt ja rein gar nicht wenn man eine tolle, Threadbasierte Applikation entwickelt und das OS die ganzen Programmierbemühungen
zurnichte macht, weil der Kernel eben nicht über alle CPU’s so skaliert wie es für eine Parallelisierung sinnvoll wäre.

  1. “die Performance” gibt es nicht - schon garnicht wenn du allgemeine problemstellungen zwischen blockierenden und nicht blockierenden nebenlaeufigkeiten betrachtest

  2. es eher unwahrscheinlich, dass die implementation des threadings (system) selbst irgendeine signifikante rolle bei einer -> Webanwendung spielt. dieser aspekt ist dort definitiv kein engpass

Also ich hatte entweder mit keiner oder wenn dann aber mit einer fundierten Antwort gerechnet. Deine war weder fundiert, noch das Thema reflektierend und verstanden hast Du auch nichts. Lass es am besten.

Danke!

Es gab mal Zeiten, da waren die Festplatten der Flaschenhals. Irgendwann danach war es der Hauptspeicher. Die CPU ist sowieso immer zu langsam und verbraucht zusätzlich auch noch zuviel Strom.
Ok, ernsthaft: Threading und geforkte Prozesse gibt es schon eine Weile, die massiv parallelen CPUs sind aber recht neu in der Hardware Welt. Die Programmiertechniken in herkömmlichen OS sind einfach nicht auf so etwas ausgelegt und es wird auch eine Weile dauern, bis sich daran etwas ändert. Hinzu kommen GPUs, die heute schon auf massiv paralleles Berechnen ausgelegt sind und derzeit nur mit speziellen Bibliotheken vernünftig nutzbar sind.

Wenn ich mir nur anschaue, wie stark ein einzelner globaler Spinlock ein herkömmliches System blockiert und wie sich die Situation in einem massiv parallelen System entwickelt …

Persönlich denke ich, dass die Entwicklung weg von einer großen, starren Anwendung hin zu vielen kleinen (Teil)anwendungen gehen wird, die alle (quasi) unabhängig voneinander laufen können. In so einem System kannst du ggf. Tausende Prozesse parallel ausführen, ohne das sich diese gegenseitig stören. Quasi viele kleine Sandboxen. Nur auf die Art kannst du auf die veränderten Rahmenbedingungen reagieren und die anfallende Rechenlast auf alle vorhandenen Resourcen verteilen.

Dann ist das aber ein großes generelles Problem. Ich meine wenn ich unter Linux was mit Threads machen will, dann definiere ich die zwar in meinem Source, aber der SMP Kernel sagt dann wann und wo meine Threads laufen. Unter Windows ist das mit SMP eigentlich ein großer Witz, da muss ich mich komplett selber drum kümmern und mehr als 8 CPU’s sind sogar bei den teuren Server Editionen nicht so ohne weiteres drin.Wenn aber Linux/Unix Threads/Forks nicht sauber an die Cores die da sind verteilen kann, dann nützt mir ja auch meine ausgefeiltestes Thread Programm nichts wenn ich skalieren möchte. Die Java JVM kapselt das sogar noch. Sie läuft wie mein C Programm auf dem SMP Kernel und Threaded und Forkt unter Linux/Unix munter drauf loß. Nach dem Comet Async Test Bericht ist aber klar, das zumindest unter Linux noch erheblicher Nachbesserungsbedarf auf unterster Schiene im Kernel besteht. Wie schaut das da im Gegenzug z.B mit Solaris oder FreeBSD aus? Solaris war offenbar einer der ersten Multi CPU Betriebssysteme. Bezieht sich das nun wieder nur auf Sparc oder auch die AMD64
CPU’s ?

Es kommt mir schon sehr komisch vor das alle paar Monate mehr Cores in den Rechnern verbaut werden und die Betriebssysteme das gar nicht richtig
ausnutzen, das macht irgendwie keinen großen Sinn… Sogar bei der PS/3 “CELL” scheint es für die Entwickler gar nicht so trivial zu sein die angebotene
Parallelisierung richtig zu nutzen.

Richtig. Und das würde auch wunderbar funktionieren, wenn es nicht trotzdem Operationen gibt, die zwischen allen Threads abgestimmt werden müssen.

Als Beispiel: wenn zwei Threads auf den gleichen Speicherbereich zugreifen wollen, aber auf verschiedenen CPUs laufen, bremsen sie sich trotzdem gegenseitig aus. Das ist aber eine Frage der Aufgabenstellung und des Betriebssystems, nicht der eigentlichen Threadfunktionalität an sich.

Wenn es der Programmierer schafft, die Aufgaben wirklich zu parallelisieren, kann er die Arbeit über alle vorhandenen Kerne verteilen.



Unter Windows ist das mit SMP eigentlich ein großer Witz

No comment.



Es kommt mir schon sehr komisch vor das alle paar Monate mehr Cores in den Rechnern verbaut werden und die Betriebssysteme das gar nicht richtig ausnutzen, das macht irgendwie keinen großen Sinn.

Wenn du - wie jetzt - drüber nachdenkst, merkst du das. Aber für die Masse ist das schlicht nur: “Mehr = Besser”. Die Marketingabteilungen der Prozessorhersteller lassen die Leute auch brav in dem Glauben.



Sogar bei der PS/3 “CELL” scheint es für die Entwickler gar nicht so trivial zu sein die angebotene Parallelisierung richtig zu nutzen.

Es hat halt keiner so wirlkliche Erfahrung damit.
Die ersten, die das ausgenutzt haben, waren gleich mal Programme zum Berechnen von großen Datenmengen. Dafür war die PS3 zwar nicht gedacht, aber in diesem Bereich gibt es bereits massive Erfahrungen, wie man Arbeiten über Tausende Rechner verteilt.

und jetzt finden wir mal den Bogen zurueck zu einer web-anwendung - kontextfrei war das OP nicht, es wurde u.a. Ajax genannt …

und Ajax als Client Counterpart einsetzen. Ajax erlaubt es bekanntlich nur bestimmte Teile einer Website neu zu laden, anstatt die ganze Seite neu anzufordern. Das dumme ist nur, bisher wurde dafür am Webserver jeweils ein neuer Workerthread gestartet.

und schon stellen wir fest, dass “mehr = besser” durchaus eine sinnvolle formel darstellt, weil sich threading-konzepte im OS oder support durch CPU-typ auf einem unverwandtem abstraktionsniveau abspielen … “mehr = besser” hat zwar mit der frage wenig zu tun - aber wenigstens führt sie zu fruchtigen erkenntnissen/lösungen - nämlich was passiert wenn ich tatsaechlich gleichzeitig viele requests zu bearbeiten habe … so ein thread zu erzeugen geht im netzwerk unter (latenz) - zuwenig prozessorzeit hingegen spuert man mitunter sehr deutlich. ersteres manko laesst sich durch pools zudem sehr elegant lösen - was ja auch getan wird.

weiterhin muss beachtet werden, dass es nachwievor durchaus ueblich ist, serverseitig keine threads zu starten - sondern prozesse geforkt werden - was erheblich “teurer” als erstere variante - das nimmt man aber aus anderen bekannten gründen in kauf.

die ganze frage eruebrigt sich somit wegen dem aufgaben-schwerpunkt des vorgegebenen kontext.

aber gross rumtönen

Beweise das bitte.

postgres :slight_smile: auch apache wird so gern betrieben

oder brauchst du eine erklaerung, warum prozesse erzeugen teurer ist als die erzeugung von threads?

Warum wohl?


oder brauchst du eine erklaerung, warum prozesse erzeugen teurer ist als die erzeugung von threads?

Ja, danach fragte ich dich.
Und vor allem auch nach einigen Zahlen zu deiner Behauptung.

es ist einfacher zu implementieren … das “verfahren” steht auf jeder plattform zur verfuegung - und das auch noch mit beinahe einheitlich wirkender api … das gesamtsystem ist vgl.weise stabiler (wenn ein client-prozess abschmiert bleiben die andern am leben) … von sicherheitsaspekten rede ich noch garnicht … usw. … ich will hier ja garkeine debatte losreissen in der es um “was ist besser” geht … es gibt fuer und widers

dafuer braucht ich keine zahlen - es muss billiger sein, selbst prozess-wechsel sind teurer als ein thread wechsel

das ist die logische konsequenz dessen, was bei diesen wechseln alles passieren muss - bzw. nicht passieren muss wenn man auf “echtes” threading setzt.

es gibt google - und jede menge literatur (amazon).

insgesamt ist das ein standard-thema fuer jeden ambitionierten softwareentwickler … da muss man auch bei google kein voodoo eingeben um brauchbare ergebnisse zu erhalten … einer von beiden begriffen reicht schon um einen vgl zum anderen zu finden …

Du nicht, aber wenn du das behauptest, beweise das bitte auch.


es gibt google - und jede menge literatur (amazon).

Du, ich will mir hier von dir nicht anhören, dass ich mir selbst die Beweise für deine Aussagen zusammensuchen soll. Das ist deine Aufgabe.


insgesamt ist das ein standard-thema fuer jeden ambitionierten softwareentwickler

Wohingegen du dich damit noch nicht sonderlich beschäftigt hast.


… da muss man auch bei google kein voodoo eingeben um brauchbare ergebnisse zu erhalten … einer von beiden begriffen reicht schon um einen vgl zum anderen zu finden …

Dann mal los, lass dich nicht aufhalten.

nagut …

ohje

Aber du brauchst weniger Halbwissen. Da du nicht in der Lage bist, deine eigenen Aussagen zu beweisen, drehe ich das mal um.

Der Linux Kernel verwendet z. B. die gleiche Infrastruktur für Threads und Prozesse. Wirf mal einen Blick in das Unterverzeichnis “kernel/” im aktuellen Linux-Kernel. Einfachste Überlegung: die Threads bekommen auch verschiedene PIDs zugewiesen und sind rein technisch unterschiedliche Prozesse, werden nur etwas anders gehandhabt (die Prozesse dürfen sich z. B. gegenseitig in den Speicher schauen).

Moderne Betriebssysteme implementieren Copy-on-Write. Der gemeinsame Speicherbereich zweier (oder vieler) Prozesse wird solange nicht kopiert, wie dies nicht notwendig ist. Nur wenn sich Daten ändern, werden die Daten kopiert und die entsprechenden Speicherseiten verschoben. Der Start eines neuen Prozesses unterscheidet sich damit nicht viel vom Start eines Threads.

Hinzu kommt, dass in einer Thread-Implementierung diverse (ganz viele) Locks notwendig sind, um Ressourcen gegen andere Threads zu sperren. Dies ist in einem Prozess-orientierten Vorgehen nicht notwendig. Diese Locks bremsen wiederum alle anderen Threads aus, so dass die Anwendung insgesamt langsamer wird.

Das nächste Mal informier dich einfach vorher. Aber wem sage ich das …
Threads mögen für bestimmte Aufgabenstellungen gut sein, aber es gibt sehr gute - und sehr viele - Gründe, davon die Hände zu lassen.

nein … threads laufen im gleichen adressraum … prozesse nicht - jeder prozess hat sein eigenes datensegment - ausserdem muessen bei einem prozesswechsel systemressourcen vom OS geswitched werden - bei threads (beinahe) nicht (bis auf den prozessor soferns nicht mehrere sind). das ist der grund warum man threads erfunden hat - weniger kostspielig in jeder hinsicht.

unter linux hat man lange zeit auf threads verzichtet, weil man der meinung war, dass man das nicht braucht, da fork() ausreichend effizient implementiert wurde. inzwischen gibts das eben auch dort - ganz sicher nicht aus langer weile der Entwickler. (fork gibt es uebrigends unter windows so garnicht)

das ist (v.a.) eine unixoide optimierung - damit fork schoen schnell ist. auch hier liegst du wieder daneben - denn copy-on-write spielt keine rolle beim threading - weil threads bekannter massen im selben datensegement laufen SOLLEN … da wird der zugriff synchronisiert (das entscheidet die anwendung) und keine daten kopiert.

doch - erheblich - siehe oben …

falsch - bei Threads musst du dich als Entwickler der Anwendung GRUNDSÄTZLICH selbst um die synchronisation von systemresourcen kuemmern. Bei parallelen Prozessen übernimmt vieles das OS - ein weiterer Grund warum Prozesswechsel i.d.R. teurer sind als jene von Threads - auch weil ich als Multithreading-Entwickler bei der synch. wesentlich spezifischer auf das gestellte Problem eingehen kann.

Das nächste Mal informier dich einfach vorher. …

genau!

Der Nachteil des Threadings ist hauptsaechlich, dass allg. Speicherschutzmechanismen des OS nicht beruecksichtigt werden (selbes Datensegment) … d.h. wäre Postgres z.B. threadorietiert, dann koennten Fehler z.B. zu wildem Herumschreiben in den Daten anderer Connections führen (sind ja im selben Prozess). … Außerdem kacken alle Clients ab, sobald der einzige Prozess der existiert wegen einem Fehler abnippelt. Weiterhin muss man je nach Aufgabe größeren Aufwand beim Implementieren betreiben … Synchronisation eben … man erhaelt nicht pauschal mehr Locks dadruch - sie werden nur offensichtlicher (im Code) - auch das OS muss einen Prozess blockieren, wenn ein anderer die selbe Resource verwendet … dort passiert das halt (verallgemeinert) undifferenzierter und somit öfter.

Sorry symbiont, aber im Gegensatz zu Dir kann Ads mit Fakten und sauber
strukturierten Schilderungen aufwarten.

Back to Topic:

Loßgetreten hat für mich die ganze Debatte ein Blobeitrag auf Comet Daily,
eine Developer Blog wo es einerseits um Serverside Blocking / non Blocking
Threading geht (im Kontext von Tomcat) und vom Server ausgelöste
Events die den angeschlossenen Ajax Client ohne Polling darüber informieren
das sich am Server ein Ergeignis ergeben hat, auf das der Ajax Client reagieren
soll.

Abstrakt:
Natürlich befasst sich der Author des Eintrags in erster Lininie um die Java
Implementierung von Comet in Tomcat 6.20 und der kommenden Version 7.
Seit die neuen JVM’s nun auch non Blocking Threading bieten (via NIO)
wurde in der Comet-Szene die Ansicht vetreten das dieses Verfahren besser
und kosteneffizienter wäre als klassiche Blocking-Workerthreads für jeden
einzelnen Ajax Client der die Verindung hält. Die Paismessungen des Authors
lieferten jedoch im Realitycheck fast identische Lesitungskenndaten wie
die klassischen Blocking Threads. Das ganze Testszenario wurde dann
noch mal weiter aufgebohrt und sogar in einer Supercomputing Umgebung
wiederholt getestet, jedoch zeigt sich auch hier kein anderes Verhalten.
Völlig verwirrt suchte Der Author sich den Rat bei einem Google Engineer
der die ganze Sache dann mit folgendem Statement aufklärte:

The “Revelation”
As a frequent reader of javalobby.org, one day I found an article on avoiding NIO to get better throughput. Dan Dyer cited the blog and a paper of Paul Tyma, a Software Engineer at Google. In his research paper, Paul destroys, with humor and with some tests, the typical well established myths about the superiority of performance and scalability of NIO against IO. I must recognize that I was shocked with Paul’s investigations and soon realized the correlation with long-polling.

First of all, in any system, threads are basically pieces of memory:
stacks and state registries. There is no correspondence between
threads and hardware.

Furthermore, usually any processor (or core) is almost a single-thread processor. in other words, a very very small number of running threads completely fulfills the “real” parallelism of any average computer.

The parallelism of threading is an illusion and thread management is
basically a software problem with some necessary support of hardware.

Managing tons of threads is not a hardware problem, but one with software. For example, consider a single core processor saturated with two threads doing some non-blocking tasks. If in a single-real-thread-processor one task needs X time to complete, Y threads doing the same need X*Y as a minimum and in ideal circumstances (in this extreme case threading cost is 0), but the parallelism sensation is important and justifies threading.

The problem of many threads is that the performance cost is significant:
Thread switching has a cost, and this may increase when more threads are added.Uncontended synchronization (calling a synchronized method not blocked) has a cost. Contended synchronization has a cost.
The thread stack occupies memory.

Comet Daily » Blog Archive » Is it Raining Comets and Threads… Again?


Meine Überlegungen
Ok, es handelt sich nicht um ein JVM oder Java Phänomen sondern um ein generelles OS/Application-Problem .Da die Threads oder Forks jedoch vom OS erzeugt werden (der OS Kernel macht das ja, nicht das eigene Usermode Programm) scheint es mir besonders spannend zu sein wie effizient dies auf OS Ebene geschieht. Seit Linux Kernel 2.6 wird ja offiziell NTPL
verwendet, davor war es es wohl ziemlich grausam. Aber angefangen hat mit der ganzn Threading Thematik offenbar Ende der 80er Jahre SUN und SunOS/Solaris war das erste Multitreaded Fähige System.Da stellte sich mir jetzt die praktische Frage ob da eventuell ein Voteil im Thread/Fork Management Bereich besteht, weil die einfach mehr Zeit hatten.
Das ist zumindest erstmal mein naive Vermutung.Kann ja aber auch sein,das Linux z.B im Zusammenhang mit den besseren
Intel Hyperthreading Punkten kann und overall besser im Endergebnis da steht.

Na gut, da der Thread (welches Wortspiel) noch mal aufgegriffen wurde, noch ein paar Kommentare:

In einigen Hinsichten, nicht in allen.


das ist (v.a.) eine unixoide optimierung - damit fork schoen schnell ist. auch hier liegst du wieder daneben - denn copy-on-write spielt keine rolle beim threading - weil threads bekannter massen im selben datensegement laufen SOLLEN … da wird der zugriff synchronisiert (das entscheidet die anwendung) und keine daten kopiert.

Ich habe auch nicht gesagt, dass Copy-on-Write eine Rolle bei Threads spielt. Im Gegenteil, Copy-on-Write spielt eine große Rolle beim fork(): Es werden quasi nur die Prozessinformationen kopiert und das geht schnell. Der gesamte Speicher des Prozesses bleibt wie er ist, solange niemand selbigen ändert. Damit ist ein fork() vom Aufwand (und der Performance) her nicht viel anders als das Erzeugen eines neuen Threads, nur wird halt kein Eintrag in die Tabelle mit Threads sondern in die Tabelle mit Prozessen geschrieben.


Der Nachteil des Threadings ist hauptsaechlich, dass allg. Speicherschutzmechanismen des OS nicht beruecksichtigt werden (selbes Datensegment) … d.h. wäre Postgres z.B. threadorietiert, dann koennten Fehler z.B. zu wildem Herumschreiben in den Daten anderer Connections führen (sind ja im selben Prozess). … Außerdem kacken alle Clients ab, sobald der einzige Prozess der existiert wegen einem Fehler abnippelt.

Das ist sogar ein gravierender Nachteil. Wie will man in so einer Umgebung die Datensicherheit garantieren können?

Synchronisation eben … man erhaelt nicht pauschal mehr Locks dadruch - sie werden nur offensichtlicher (im Code) - auch das OS muss einen Prozess blockieren, wenn ein anderer die selbe Resource verwendet … dort passiert das halt (verallgemeinert) undifferenzierter und somit öfter.

Und schon sind wir wieder beim Thema des Threads:
Wenn zwei Threads, die auf dem gleichen Prozessor laufen, zu synchronisieren sind, passiert das im L1 oder L2 Cache des Prozessors. Schön. Was ist, wenn das massiv parallel auf vielen Cores betrieben wird? Dann muss jedweger schreibender - und ggf. auch diverse lesende (Stichwort: volatile Daten) - Speicherzugriff der Threads miteinander synchronisiert werden, über Prozessorebenen hinweg. Auch das ist ein Lock, aber dieser Lock ist nur in Threads notwendig, nicht bei getrennten Prozessen. Da die Anzahl der notwendigen Locks mit der Anzahl der Threads und Cores ansteigt, kann das die Abarbeitung sogar mehr ausbremsen als die möglichen Verluste durch getrennte Prozesse.

Bleibt festzuhalten: sowohl Threads wie auch getrennte Prozesse haben ihre Vor- und Nachteile. Man sollte diese gut gegeneinander abwägen. Pauschale Aussagen, was schneller oder besser ist, kann man ohne Kentniss des Anwendungsfalls nicht treffen.

Back to Topic:
Loßgetreten hat für mich die ganze Debatte ein Blobeitrag auf Comet Daily,eine Developer Blog wo es einerseits um Serverside Blocking / non Blocking
Threading geht (im Kontext von Tomcat als Webserver) und vom Server ausgelöste Events die den angeschlossenen Ajax Client ohne Polling darüber informieren das sich am Server ein Ergeignis ergeben hat, auf das der Ajax Client reagieren sollte.

The “Revelation”
Dan Dyer cited the blog and a paper of Paul Tyma, a Software Engineer at Google. In his research paper, Paul destroys, with humor and with some tests, the typical well established myths about the superiority of performance and scalability of NIO against IO. I must recognize that I was shocked with Paul’s investigations.

First of all, in any system, threads are basically pieces of memory stacks and state registries. There is no correspondence between Threads and hardware.

Furthermore, usually any processor (or core) is almost a single-thread processor. in other words, a very very small number of running threads completely fulfills the “real” parallelism of any average computer.

The parallelism of threading is an illusion and thread management is basically a software problem with some necessary support of hardware.

Managing tons of threads is not a hardware problem, but one with software. For example, consider a single core processor saturated with two threads doing some non-blocking tasks. If in a single-real-thread-processor one task needs X time to complete, Y threads doing the same need X*Y as a minimum and in ideal circumstances (in this extreme case threading cost is 0), but the parallelism sensation is important and justifies threading.

The problem of many threads is that the performance cost is significant:
Thread switching has a cost, and this may increase when more threads are added.Uncontended synchronization (calling a synchronized method not blocked) has a cost. Contended synchronization has a cost.The thread stack occupies memory.

Überlegungen:
Es handelt sich also um ein generelles Applikations Threadingdesign sowie als auch um ein SMP Kernel spezifisches Problem auf unterster Schicht.
Ich müsste vermutlich nur herausfinden wie Threadobjekte in Java beschaffen sein müssen damit die JVM es in korrekter, parallelisierter Form weiter reicht, dafür muss es ja - ähnlich wie bei den PostgreSQL Execution plans Bedingungen geben die besser oder weniger besser geeignet sind. Da die Threads oder Forks jedoch vom OS erzeugt werden (der OS Kernelübernimmmt das ja und nicht das eigene Usermode Programm) scheint es mir besonders spannend zu sein wie effizient dies auf OS Ebene geschieht. Seit Linux Kernel 2.6 wird ja offiziell das NTPL-System verwendet.Aber angefangen hat mit der ganzen Threading Thematik offenbar Ende der 80er Jahre SUN (SunOS/Solaris war das erste Threadfähige OS).Da stellt sich mir jetzt die praktische Frage ob da eventuell ein Voteil im Thread/Fork Management besteht, weil die einfach mehr Zeit hatten.Kann ja aber auch gut angehen das Linux z.B im Zusammenhang mit dem besseren Intel Hyperthreading Punkten kann und im Endergebnis doch besser da steht, obwohl es dabei eher wenigerprimär um multicore und Parallelisierung und damit core basiertes skalieren geht.

Comet Daily
Comet Daily » Blog Archive » Is it Raining Comets and Threads… Again?

Es geht also vorrangig um Tomcat bzw. Servlet-Container - damit geht es also doch “nur” um Threads im eigentlichen Sinne, da Tomcat eine Java-Lösung ist - und Java “nur” Threads kennt. D.h. Client-Requests werden durch Threads getrennt …

Nun kannst Du recherchieren, ob überhaupt und auf welchem OS Java-Threading “performanter” funktioniert …

Die aktuelle Java Spezifikation (1.6 und auch 7) schreibt nicht vor wie die JVM Native das Threadhandling gegen das OS implementieren muss.In den alten Java JVM’s gab es das Green Threading, da spielten sich alle Threads tatsächlich innerhalb der JVM selbst ab.Das hat sich aber grundlegend geändert.Mittlerweile forkt die JVM unter Linux und Unix und unter Windows werden die native API Methoden (Win32/Win64) zum kreaieren der Threads verwendet.Gott sei dank hat SUN die Delegation der Threads pro Core/CPU unter Windows fest in die JVM integriert und dieses heikle Thema geregelt. Sprich: Die JVM weiß selbst wann welcher Core unter Windows wann welche Threads zugewiesen bekommt (SMP und MS:Wieder mal so ein Schrottdesign von denen das der intension von SMP nicht im geringsten gerecht wird) und der Programmierer muss sich z.B im native C/C++ Bereich hier mal wieder selbst um alles kümmern.

Nun kannst Du recherchieren, ob überhaupt und auf welchem OS Java-Threading “performanter” funktioniert …

Das habe ich vor dem Posting hier versucht, bin aber nicht fündig geworden.Es ist auf jeden Fall schon mal gut zu wissen, dass das
OS eine entscheidende Rolle spielt.Denn es nützt leider rein gar nichts, wenn man seine Programmlogik hinsichtlich Threads optimiert aber das OS alls wieder zunichte macht oder in dem es z.B intern doch nur wieder alles auf einen Core verlagert.