Elessar said:
Die grossen Unix Desktop Environments sind meist iirc singlethreaded aber mit mehreren Prozessen. Auf Windowsplattformen finden sich weniger Prozesse, dafür mehr Threads. Dies liegt einfach daran, dass auf Unix Prozesse, auf Windows Threads "billig" sind. Traditionell jedenfalls. Auf Dragonfly dürften Threads billiger sein (Vermutung).
Mh, das stimmt glaube ich nicht.
Von der Idee her ist das Erzeugen eines neuen Threads immer billiger als ein neuer Prozess, denn ein Thread benutzt denselben Speicherbereich und dieselben sonstigen Ressourcen wie der Prozess, zu dem er gehört. Das gilt unabhängig vom OS, gilt also für Windows genauso wie für Linux und die BSDs.
Siehe auch den
Wikipedia-Eintrag zu Threads
Es ist halt nur so, daß unixartige Systeme traditionell eine eher schlechte Unterstützung für Threads gehabt haben. Das betrifft sowohl Probleme hinsichtlich der Zuverlässigkeit als auch Probleme mit der Skalierbarkeit bei vielen Threads als auch Effiziensprobleme im Multithreadingbetrieb.
Erst in den letzten Jahren hat sich da so richtig viel geändert. Mittlerweile gibt es einige ganze Reihe an Neuentwicklungen mit verschiedenen Stärken und Schwächen für verschiedene Situationen.
Es ist wichtig, daß das OS eine gute Unterstüzung für Thread bietet. Aber das allein reicht noch nicht aus. Das Problem ist nämlich, daß man vorhandenen single Thread Code aus Anwendungen und Bibliotheken nicht mal eben so umgestalten kann, daß mehrere Threads benutzt werden. Das ist kompliziert, und es gibt eine Menge zu beachten, damit man sich keine Race Conditions, deadlocks und so weiter einhandelt.
SMP ist dann wieder ein ganz anderes Thema. Bislang ging es in meinem Beitrag ja darum, daß Software unter unixartigen Systemen in der Vergangenheit selten mehrere Threads benutzt hat, obwohl das in vielen Fällen die natürliche Vorgehensweise gewesen wäre. Stattdessen haben viele Softwareprodukte entweder alles in einem einzigen Prozess mit einem Thread erledigt (und haben Parallelausführungen intern selbst gemanaged), oder sie haben mehrere Prozesse benutzt, die dann über verschiedenden Techniken miteinander kommuniziert haben (etwas über
shared memory). Beide Lösungen haben den Programmierern einen erheblichen Aufwand aufgebürdet, der sich mit einer ordentlichen Thread-Unterstüzung des OSes erheblich hätte verringern lassen.
Bei SMP-Skalierbarkeit geht es aber nicht mehr um die Frage, wieviele Threads man für Problem X natürlicherweise erzeugen würde, sondern wieviele man überhaupt maximal erzeugen kann. Diese Zahl ist nämlich oft einfach begrenzt. MySQL arbeitet zwar multithreaded, bearbeitet aber eine Anfrage immer nur mit einem Thread. Ein einzelnes SELECT Kommando ist also auch auf einem System mit 64 CPUs nicht schneller als auf demselben System mit nur einer aktivierten CPU. Bei Apache mit dem worker mpm ist es dasselbe: Ein Thread wird natürlicherweise für eine Anfrage benutzt. Und eine CPU reicht von der Leistung her ja für eine Anfrage aus.
Aber wenn ein einzelnes zu bearbeitendes Problem schon so aufwendig ist, daß man sich wünscht, von mehreren CPUs profitieren zu können, dann stellt man oft fest, daß das nicht so ohne weiteres möglich ist, weil die zugrundeliegenden Algorithmen sich nicht so ohne weiteres parallelisieren lassen. Zumindest nicht in dem Sinne, daß mehrere Threads benutzt werden können, die mehrere CPUs gleichzeitig auslasten können. Ein kleines Beispiel, wo das gelungen ist, ist eine Änderung/Neuimplementierung des bzip2-Algorithmus, siehe
http://compression.ca/pbzip2/ Aber bei vielen Algorithmen hat man überhaupt noch keine Möglichkeit gefunden, sie zu parallelisieren.
Zusammenfassung:
Ich bin absolut dafür, daß mehr Software für unixartige Systeme Threads benutzt, wo es ein natürliches Bedürfnis ist. Ich glaube auch, daß es einen erheblichen Aufwand bedeuten würde, diverse OpenSource Produkte und Libraries auf die Verwendung von Threads umzuschreiben. Aber ich bin der Ansicht, daß der Typ, der diesen ACM Queue Artikel geschrieben hat, keine Ahnung hat, daß es nicht mal eben so ohne weiteres durch hinzufügen von Threads möglich ist, daß eine einzelne Anwendung auf 100 CPUs hundert mal so schnell läuft wie auf einer CPU.