Warum wurden Threads nie als Teil des C ++ - Standards eingefügt?

Ich denke, die Hauptgründe sind

• das Einfädeln von Threads in die Sprache erfordert viel Arbeit und Verständnis, die damals noch niemand hatte
• niemand hatte eine großartige Idee über eine gute threading-API, und es gab keine existierende Bibliothek, die gut genug schien, um als Grundlage für weitere Arbeit verwendet zu werden
• Das Standardisierungskomitee war mit genug anderer Arbeit überhäuft (wie die Einführung der STL in die Standardbibliothek)
Dieser Standard war so spät wie er war; Es dauerte mehr als zehn Jahre, bis die erste Version erschien, mit ziemlich viel Verspätung aufgrund von "Last-Minute-Änderungen" ( std::auto_ptr , STL), und ich denke, das Hauptgefühl war, etwas früher zu haben als zu behalten Warten auf einen unendlich verzögerten perfekten Standard; Ich denke, damals glaubten die meisten Leute nicht, dass es so lange dauern würde, bis die nächste Version fertiggestellt wäre

Nach der Ratifizierung des Standards wurde boost von Mitgliedern der Bibliotheksarbeitsgruppe als Testumgebung für Bibliotheken gegründet, die in der Standardbibliothek wünschenswert waren, für die aber nicht genügend Zeit für die endgültige Version zur Verfügung stand. Dort wurde ein großer Teil der Arbeit erledigt, die für das Hinzufügen von Threading-Unterstützung zu C ++ erforderlich ist (nämlich das Entwickeln einer guten Threading-Bibliothek).

Tatsächlich gab es Threads, als C ++ in den neunziger Jahren standardisiert wurde. Windows und Posix haben jedoch sehr unterschiedliche Threading-APIs. Entwerfen einer Bibliothek von der Qualität, die Sie von einer Standardsprachenbibliothek wünschen, die alle Threading-Primitiven, die Sie benötigen, und Mapping gut auf beide gängigen APIs (und andere), erfordert einen großen Aufwand. Die Aufnahme in den ursprünglichen Standard hätte entweder eine Verzögerung der Standardisierung erforderlich gemacht, möglicherweise für Jahre, oder eine Spezifikation, die möglicherweise erhebliche Mängel aufweist.

Diese Arbeit wurde in den letzten zehn Jahren (ursprünglich als Boost.Thread-Bibliothek) ausgeführt und wird in der nächsten Version des Standards neben den Funktionen auf Sprachenebene, wie z als thread-lokaler Speicher.

Es gibt eine Menge Arbeit beim Erstellen einer Thread-Klasse und C ++ 0x hat dies größtenteils durch Hinzufügen der Thread-, Mutex- und atomaren Bibliotheken erreicht, aber es hat eine Menge Arbeit von vielen Leuten erfordert.

Denken Sie daran, dass C ++ eine sehr große Sprache ist und Änderungen aufgrund der Komplexität der Sprache und der Menge an Code und der Industrie, die darauf basieren, ziemlich langsam erfolgen. Es dauert lange, um Änderungen in den Standard zu ratifizieren.

Threading und Synchronisation war in der Regel eine vom Betriebssystem bereitgestellte Funktionalität, so dass Ergänzungen mit den gängigen Implementierungen kompatibel sein mussten und ohne massive Änderungen an den Plattformen möglich waren (oder niemand in der Lage wäre, den Standard zu implementieren).

Technisch ist es nicht ausreichend, nur eine Thread-API hinzuzufügen, C ++ fehlte auch ein kohäsives Speichermodell, dh wie interagieren die Variablen über den Thread und wie können wir die breite Palette von Speichermodellen im Code ausdrücken? prägnant (und performant). Die meisten von uns haben das Glück, auf x86-basierter Single-Threaded-Software zu arbeiten, die ein sehr fehlerverzeihendes Speichermodell hat, aber es gibt andere Hardware, die aus Speicherperspektive nicht so fehlerverzeihend ist und bei der Leistungseinbußen ziemlich hart sein können.

Die Bibliothek behebt das Problem des Speichermodells, indem atomare Variablen mit fehlerverzeihenden Standardwerten und expliziter Steuerung versehen werden.

Die Bibliothek bietet einen weiteren wichtigen Teil der Funktionalität für portierbares Threading durch Bereitstellung von Synchronisationsklassen.

Schließlich wurde hinzugefügt, und wenn Sie nicht den Verlauf auf der Arbeitsgruppe Website gelesen haben, ist es interessant, aber einfach ersetzen CreateThread, QueueUserWorkItem oder ein pthread Aufruf war ein Thread-Objekt ist nicht genug. Thread-Lebenszeit, Status-Management und lokaler Thread-Speicher mussten alle durchdacht werden.

All dies hat lange gedauert, bis es richtig war, und wie andere bereits erwähnt haben, war das meiste schon eine Weile im Aufwind, um sicherzustellen, dass wichtige Fragen bearbeitet wurden und es zusammenhing, bevor es in den neuen Standard aufgenommen wurde.

Weil die Autoren kein bestimmtes Verhalten auf Implementierern erzwingen wollten.

Threads sind eine Sache mit dem Betriebssystem, sie sind also nicht wirklich eine Funktion der Programmiersprache, sondern vielmehr die Bibliotheken, die vom System zur Verfügung gestellt werden. POSIX-Threads zum Beispiel können in C ++ verwendet werden, sind aber nicht wirklich "Teil" davon.

Eine der Herausforderungen, vor der das Standardkomitee vor zwölf Jahren stand, sind die Unterschiede in der parallelen Hardware. Ein Hauptunterscheidungsmerkmal zwischen verschiedenen Hochleistungsrechenarchitekturen ist die Art und Weise, wie die Parallelberechnung erlaubt wird, und nur eines dieser vielen Modelle ist der Posix-Thread-Abstraktion SMP wirklich ähnlich.

Wenn Sie diese Situation mit der der Fortran-Sprache vergleichen, die speziell auf diese Art von Hardware abzielt, sehen Sie, dass jeder Anbieter einen Fortran-Compiler anbietet, den er erweitert hat, um die speziellen, von der Hardware bereitgestellten parallelen Rechenfunktionen zu unterstützen.

Dies kann in der heutigen Zeit als relevant angesehen werden, indem typische x86 / x64 White-Box-Rechenknoten, die normalerweise bis zu 4 Sockets haben, in 24 Kerne mit einem einzigen gemeinsamen Speicher zu einem Gaming-PC mit mehreren nVidia oder AMD verglichen werden GPUs. Beide sind in der Lage, den Durchsatz zu erhöhen, aber um das Beste aus ihnen herauszuholen, ist ein sehr unterschiedlicher Programmierstil erforderlich. In der Tat arbeiten unterschiedliche Workloads deutlich besser auf einer Architektur als auf der anderen, abhängig von der genauen Art des spezifischen Algorithmus.

Vor diesem Hintergrund war es wahrscheinlich vor zwölf Jahren für den Standardausschuss nicht möglich, zu ermitteln, wie er diese Probleme angehen sollte. Jetzt jedoch ist die Antwort viel einfacher. C ++ zielt nicht auf etwas anderes als SMP-Hardware; diese werden von anderen Sprachen und Tool-Ketten wie OpenCL oder VHDL bedient.

Weil sie vom Betriebssystem abhängig sind. I.E. unix / linux / macosx benutzt pthread API, Windows benutzt eine eigene API und so weiter ...

Sie könnten in libstdc++ enthalten sein, aber ich denke, es ist nicht einfach, alle aktuellen und zukünftigen Thread-Funktionen in eine gemeinsame API einzubinden. Auf die gleiche Weise ist der DB-Zugriff nicht in libstdc++ enthalten.