Systemunabhängiges Threading in C/C++

[Besserwissend]

Hallo,

ich spiele gerade ein bischen mit POSIX-Threads (Pthreads) in C/C++ herum. Ich bin mit dem ganzen Parallelkram noch absolut "frisch" und hab deswegen mal ein paar Fragen.

Wenn ich meine Code gegen pthreads-Bibliothek in *ix, *ux, *BSD und Win*-Systeme linke, "erzeuge" ich doch Kernel-Level-Threads, oder?

Gibt es eine (betriebs)systemunabhängige POSIX-Threads-Implementierung, die User-Level-Threads erzeugt, z.B. für Betriebssysteme, die keine natives Threading unterstützen, wie DOS, oder Systeme gänzlich "ohne" Betriebssystem?

Gibt es noch anderen möglichst (betriebs)systemunabhängig Bibliotheken, Ansätze etc. wie ich (Pseudo)Parallelität in C/C++ beschreiben kann?
Bisher hab ich nur folgendes gefunden:

- erweiterte C-Compiler: Split-C, Unified Parallel C - geht eigentlich in die Richtung OpenMP
- OpenMP: compilerabhängiges #pragma Zeug mit 1. C-untypischer hässlicher Syntax
- MPI: Message Passing Interface: Prozesse/Parallele Systeme müssen von der aufrufenden Umgebung bereitgestellt werden - eigentlich nur was für Linux und Windows + Kombination mit OpenMP
- PVM: Parallel Virtual Machines: eine MPI-Erweiterung
- diverse Mini-RTOSe, die sich als Betriebssystemprozess compilieren lassen (z.B. FreeRTOS als Windows-Prozess)

[Coda]

Evtl. http://www.boost.org/doc/libs/1_35_0/doc/html/thread.html

[robobimbo]

Oder die (imho geniale) lösung von intel: http://www.threadingbuildingblocks.com

OpenSource URL: http://threadingbuildingblocks.org/

Stellt dir verschiedene Strukturen (parallel for, hash-maps usw.) zur Verfügung. Opensource und Multiplattform

[Coda]

Hm Thread Building Blocks sieht echt gut aus. Danke für den Tipp.

Edit: Aber leider nichtmal LGPL sondern GPL. :usad:

[ManuelCalavera]

etwas OT: gibts eigentlich nen nennenswerten Performance oder andere Unterschiede zwischen Kernel- und Userlevelthreads?

[robobimbo]

Naja, prinzipiell ist User-Level-Scheduling schneller und effizienter - weil das Scheduling im Prozess selbst abläuft und niemand besser als die Applikation selbst wissen kann wie sie ihre Threads einteilen soll.

Der Nachteil ist, dass dann halt jeder Prozess seinen eigenen Scheduler mitbringt und das auch einige Ressourcen verschwendet.

Um auf deine Frage einzugehen: Kommt darauf an, wie gut der Scheduler im userlevel ist ;)

[Coda]

Userlevelthreads verwenden nur eine CPU. Das sollte die Frage beantworten ;)

[ManuelCalavera]

Danke für die Antworten :)

[Senior Sanchez]

Userlevelthreads verwenden nur eine CPU. Das sollte die Frage beantworten ;)

Wobei das ja wieder systemabhängig ist, oder? Afaik bildet Solaris Userlevel-Threads auf Kernelthreads ab und somit können dann auch mehrere Kerne genutzt werden.

[Besserwissend als Gast]

Wobei das ja wieder systemabhängig ist, oder? Afaik bildet Solaris Userlevel-Threads auf Kernelthreads ab und somit können dann auch mehrere Kerne genutzt werden.
Von User-Level-Threads weiss das Betriebssystem aber nichts (woher auch?).
Die Abbildung von User-Level-Threads auf Kernel-Level-Threads geht bei allen Programmiersprachen, die ein Bytecodeinterpreter o.ä. drunter haben wie z.B. Java. Der kann Threads des Sprachstandards auf Betriebssystemthreads (oder sogar Prozesse) abbilden, so das auch mehrere CPUs genutzt werden können.

[Coda]

Afaik bildet Solaris Userlevel-Threads auf Kernelthreads ab und somit können dann auch mehrere Kerne genutzt werden.
Naja dann sind es ja je nach Definition wieder keine Userlevel-Threads mehr.

[robobimbo]

Edit: Aber leider nichtmal LGPL sondern GPL. :usad:

Aber ich glaub da greift die runtime exception - dh. man dürfte die Lib eigentlich auch gegen komerzielle Apps linken dürfen. Obwohl Intel da keine Auskünfte dazu gibt - erstens wolles sie sich dazu sicher ned die Finger verbrennen und noch dazu die komerzielle Version verkaufen."

What is GPL v2 with the runtime exception?
GPLv2 with the runtime exception is the license under which the source code of libstdc++ is distributed (see http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html). This ‘runtime exception’ is therefore a standard for distributing template libraries – and that is why TBB uses it.

Die Komerzielle Lizenz kostet pro System (Win, Linux, OsX) ja auch "nur" 299 Dollar - was ich gar ned soooo übertrieben find.

[Gast]

Aber sind die Userlevel Threads wirklich effizienter? Zumindest im Kontext von einem Kernellevel Thread müssen ja Userlevel Threads laufen. Nämlich dem Hauptthread, der zum Prozess gehört. D.h. doch letztendlich, dass ich zwar die Userlevel Threads in meiner Anwendung schedulen kann, aber wie/wann die ausgeführt werden, richtet sich ja danach wie der Hauptthread OS gescheduled wird?! Wenn ist es doch sinnvoll, mehrere Kernelthreads von der Anwendung anstatt vom OS schedulen zu lassen.

[Coda]

Aber ich glaub da greift die runtime exception - dh. man dürfte die Lib eigentlich auch gegen komerzielle Apps linken dürfen.
Ach das ist nicht die reine GPL? Da darf man das nämlich nicht.

Die Komerzielle Lizenz kostet pro System (Win, Linux, OsX) ja auch "nur" 299 Dollar - was ich gar ned soooo übertrieben find.
Ja, aber GPL bedeutet ja dass man auch closed-source non-commercial Sachen dann nicht damit machen darf.

[robobimbo]

Aber sind die Userlevel Threads wirklich effizienter?

Der Thread alleine ist nicht effizienter - das speziell abgestimmte Prozessinterne Scheduling kann den auschlag geben.

Wenn man den Herren Tanenbaum glauben kann, gibts aber fast keine Systeme wo keine Userlevelthreads im Kernel scheduled werden.

Ja, aber GPL bedeutet ja dass man auch closed-source non-commercial Sachen dann nicht damit machen darf.

"Alle Angaben ohne Gewähr:" ;) Soweit ich es verstehe, gilt das wenn Du Quelltext veränderst, wenn Du nur die Lib verlinkst und deren Funktionen nur aufrufst dann greift eben dieser Passus

[Gast]

Ach das ist nicht die reine GPL? Da darf man das nämlich nicht.
Ist im Prinzip die selbe Lizenz wie die libstdc++ nutzt.
Also viel Spaß. ;)

[Gast]

Der Thread alleine ist nicht effizienter - das speziell abgestimmte Prozessinterne Scheduling kann den auschlag geben.


Dann muss doch aber auch der Hauptthread von der Anwendug selbst gescheduled werden. Das sollte ja über APIs gehen, aber dann laufen die Userlevel Threads trotzdem noch im Kontext vom Kernel Hauptthread, was z.B. - wie Coda schon sagte - dazu führt, dass der Code trotzdem nur auf einer CPU läuft. Insofern ist das ja heut zu Tage vollkommen rückständig. Wenn man schon selbst scheduled, dann ist es wohl sinnvoller, wenn man das mit entsprechenden Kernelthreads macht. Das macht ja z.B. auch der Microsoft SQL Server so.

[robobimbo]

Dann muss doch aber auch der Hauptthread von der Anwendug selbst gescheduled werden. Das sollte ja über APIs gehen, aber dann laufen die Userlevel Threads trotzdem noch im Kontext vom Kernel Hauptthread, was z.B. - wie Coda schon sagte - dazu führt, dass der Code trotzdem nur auf einer CPU läuft. Insofern ist das ja heut zu Tage vollkommen rückständig. Wenn man schon selbst scheduled, dann ist es wohl sinnvoller, wenn man das mit entsprechenden Kernelthreads macht. Das macht ja z.B. auch der Microsoft SQL Server so.

Wenn du es genau nimmst: Die Lib von Intel die ich das erwähnt habe, hat auch ihren eigenen Scheduler intergriert - läuft im Userspace und scheduled auch über mehrere CPU's hinweg, insofern ist das möglich.

Aber Du hast natürlich recht, der darunterliegende Kernel scheduled natürlich den einen Prozess mit. Dass das natürlich nicht immer sinnvoll ist ist auch klar, daher findet man sowas auch kaum. Aber mal sehen was uns das die Zukunft bringt.

[Gast]

Die Lib von Intel die ich das erwähnt habe, hat auch ihren eigenen Scheduler intergriert - läuft im Userspace und scheduled auch über mehrere CPU's hinweg, insofern ist das möglich.


Wie jetzt? Sind das auch wirklich Userlevel Threads? Weil ein Scheduler im Usermode ist ja jetzt nicht das Problem und wird von anderen komplexen Softwareprodukten zum Teil auch gemacht.

Man muss da etwas unterscheiden. Wenn vom schedulen (Verb) die Rede ist, dann meint man eigentlich nur, dass der Thread als "fertig" markiert wird und ausgeführt werden kann (das ausführen macht nicht der Scheduler). Auf welcher CPU der dann läuft, kann man zwar als Wunsch anfordern, aber bleibt - zumindest bei Windows - letztendlich Angelegenheit vom OS. Der Scheduler kümmert sich nur darum/priorisiert wann der Thread geschudeld (als fertig markiert) wird. Das kann man durchaus umgehen und den Kernel Thread ohne OS Scheduler schedulen.

[ollix]

Ich benutze häufig POCO (http://www.pocoproject.org/) und habe damit bisher auch sehr gute Erfahrungen gemacht; das Ding kann aber schon noch etwas mehr als Threading.

[Gast]

Der große Nachteil von User-level Threads (ULTs) ist bisher ja noch gar nicht genannt worden: Bei Ausführung eines blockierenden Systemaufrufs blockiert der ganze Prozess, also auch alle anderen Threads! Bei Kernel-Level Threads (KLTs) blockiert nur der Thread, der eben diesen blockierenden Systemaufruf gemacht hat. Alle anderen können weiterhin (vom Kern) geschedult werden.

Bei reinen ULTs weiß der Kernel ja nichts von den Threads im Userspace.

Wobei das ja wieder systemabhängig ist, oder? Afaik bildet Solaris Userlevel-Threads auf Kernelthreads ab und somit können dann auch mehrere Kerne genutzt werden.Das ist ein hybrider Ansatz und hat nichts mit reinen ULTs zu tun.
Der Thread alleine ist nicht effizienter - das speziell abgestimmte Prozessinterne Scheduling kann den auschlag geben.Was vor Allem effizienter ist, ist das Umschalten zwischen den Threads. Bei KLTs ist jedes Mal ein Kernein- und -austritt notwendig, um den Kernel-Scheduler aufzurufen. Das kostet mehrere hundert bis manchmal sogar tausend Takte. Der Wechsel im Userspace kann dagegen viel schneller erfolgen (20 oder 30 Takte).

Davon abgesehen kann jede Anwendung ihren eigenen Scheduling-Algorithmus im Userspace verwenden, der auf sie optimiert ist und muss nicht den systemweit einheitlichen Scheduling-Algorithmus des Kerns nehmen. Ich schätze letzteres aber eher weniger wichtig ein im Vergleich zum ersten Punkt.
Wenn man den Herren Tanenbaum glauben kann, gibts aber fast keine Systeme wo keine Userlevelthreads im Kernel scheduled werden.Naja, ist ja auch irgendwo klar. Threads werden verwendet, um Nebenläufigkeit auszudrücken. Wenn durch blockierende Systemaufrufe diese Nebenläufigkeit zerstört wird, indem alle Threads blockiert werden, ist das einfach Mist.

Außerdem kann man reine ULTs immer noch per Library einem Programm anbieten. Davon weiß der Kern ja nichts und muss auch nichts wissen. Aber man gewinnt eben üblicherweise quasie nichts mit reinen ULTs.

GloomY

[nurn Gast]

Um mal beim Thema zu bleiben:
In eine Programmiersprache des 21 Jahrhunderts gehört Threading/Nebenläufigkeit/Parallelität etc. meiner Meinung nach in den Sprachstandard - damit wärs auch systemunabhängig. Das Scheduling/Aufteilung auf mehrere Prozessoren, Ressourcenvergabe etc. kann dann der Compiler machen.
Wenn man sich mal das Prozessor-Portfolio des blauen Riesen oder des grünen Hobbits anschaut, dann gibt es so gut wie keine Einkern-Prozessoren mehr.
Das trifft auch auf Prozessoren für das unterste Marktsegment, wie den Intel Atom zu; das ist ja auch ein "1,5"-Core.
Einen "Sprung" bei den Taktfrequenzen gab es schon seit knapp fünf Jahren nicht mehr - 3Ghz und Sense.
Bei den eingebetteten Systemen gehts mit dem Multi-ge-kerne auch schon los - schließlich mit läßt sich Mehrfachkernen prima teure "Taktfrequenz sparen".
Um das Parallelisieren von Anwendungen kommt man in Zukunft leider nicht herum.
Blöd ist das man als Entwickler/Programmierer durch das ge-threade und ge-parallele in "klassischen" OOP/imperativen Programmiersprachen nen A**** voll Probleme bekommt:
Race Conditions, Priority Inversions, Deadlocks bla bla bla - vom Debuggen ganz zu schweigen.


Vielleicht braucht man auch was neues:
http://softwareblogs.intel.com/2007/02/23/do-we-need-another-parallel-programming-language/

Oder eine ganz andere Idee/Herangehensweise/Berechnungsmodell parallelen Programmierens - TheoInf-ler wo seit ihr wenn man euch braucht?

nur meine zwei Pfennig