Sinnvolle (portable) Threadbibliothek

[Lord Delvin]

Kennt jemand eine sinnvolle und wenns geht portable Threadbibliothek, also was mit dem man einen Thread erzeugen und verwalten kann?

Ich hab bis jetzt boost::thread verwendet und wenn man nur mal ein paar threads starten will und was ausrechnet ist das ganz gut, aber für mein derzeitiges Projekt bräuchte ich die Möglichkeit, dass sich ein Thread selbständig zur blocked liste hinzufügt und zwar ohne dafür einen Mutex zu benutzen(ich weis, dass das die normale Methode wäre, aber in meinem Fall wäre das nicht wirklich praktikabel)
Also sowas wie Block/Unblock(das dann von einem anderen thread aus), das quasi direkt mit dem Kernelscheduler redet.

Vielleicht ist das was ich mache auch einfach zu grundlegend, als dass es so ohne weiteres möglch wäre, dann müsste ich halt eine Simulation für schreiben(mit locks) und dann könnte ich keinen Benchmark mehr machen:D

Naja wäre nett wenn jeman der was weiß schreibt...(darf in dem Fall auch ne windows only version sein, linux würd ich aber bevorzugen)
Gruß
LordD

[Jörg]

Unter Windows koennte SuspendThread helfen.
Aber warum willst Du auf den Mutex verzichten? Was stoert dich?

[Matthias Gubisch]

Ich weiß jezt nich ob die genau das kann was du willst
aber ich habe sehr gute Erfahrungen mit Intels TBB (Thread Building Blocks) gemacht.

Hab den Link grad nicht da aber gibts auf alle fälle für nicht kommerzielle Software kostenlos

[Lord Delvin]

Ich mag kein Mutex, weil ichs auch ohne kann. Aber ich glaub nicht, dass es das überhaupt gibt, was ich will. Hab gestern nacht noch n bisschen gelesen und zumindest linux kanns nicht.

Hahaha. Hab mir grad das TBB RefMan durchgelesen. Das sieht mir ziemlich stark nach ner Kopie von boost aus.:)

Ich denk ich werds einfach mit boost emulieren und ma fragen ob in der uni jemand n OS kennt, dass das kann.
Aber danke trotzdem.

[Jörg]

Ich mag kein Mutex, weil ichs auch ohne kann.

Oh, dass beisst sich jetzt aber mit deiner Frage, nicht?
Ich gebe nur zu bedenken: Zum Schlafenlegen eines Threads wirst Du einen OS-Call benoetigen (es sei denn du nimmst eine user-space-only Threadbibliothek, dann ist es nur ein Funktionsaufruf). Unter Windows habe ich Dir den mitgeteilt...und am Ende ist es voellig wurscht, ob dieser Call ueber einen Mutex fuehrt oder nicht (statt Mutex kannst Du natuerlich auch socket/pipe oder sonstwas blockierendes nehmen). Insofern verstehe ich nicht, was dich objektiv daran hindert, ihn zu nehmen. Welcher praktische Grund soll dem zugrunde liegen?

[Schrompf]

Und Intels Threading Building Blocks sind deutlich mehr als nur Basiselemente für die parallele Programmierung. Klar kriegst Du da den ganzen Stapel an Mutexen, atomaren Operationen und Thread-Klassen... aber eben auch einen angeblich sehr effizienten Scheduler und ein Rudel generische Algorithmen, die Aufgaben automatisch multithread-passend segmentieren.

Die Aufgabe, Deine Algorithmen so zu schreiben, dass sie isoliert arbeiten können und keine Synchronisation mit anderen Daten brauchen, kann Dir sowieso keine Bibliothek abnehmen.

[Lord Delvin]

Hab nicht gesegen, dass TBB userland ist.

Hmm...naja ist egal...letztlich versuche ich zu beweisen, dass es auch möglich ist einen Scheduler zu schreiben, der ohne atomare Operationen auskommt(also das was sich hinter normalen kernel mutexen versteckt).
Aber durch längeres nachdenken ist mir aufgefallen, dass das NUR möglich ist, wenn man beim booten schon anfängt die nötigen strukturen aufzubauen, weil Jörg halt recht hat; ...ich werd ma schaun, ob mir unser Sysarch lehrstuhl weiter helfen kann:)

Irgendwie weigere ich mich noch n userland scheduler zu schrieben.

Naja ch glaub ich versteh langsam, was ich eignetlich machen will, und dass es wie immer doch nicht soo einfach ist:D
Gruß

[Jörg]

Waeren dann nicht Win32-Fibers was fuer dich? Die kannst Du komplett selbst verwalten...

[Lord Delvin]

Jop, Fibers hilft. Hab daraufhin rausgefunden, dass es das in etwas diffuserer Form auch für Linux gibt.

Vielen Dank:)

[fkrauthan]

du könntest auch boost verwenden. Die haben doch meines wissens auch eine Thread Lib die Multiplatform ist.

[Biolunar]

Schon im ersten Post steht, dass boost.threads bisher verwendet wurden...

[Lord Delvin]

du könntest auch boost verwenden. Die haben doch meines wissens auch eine Thread Lib die Multiplatform ist.

Um das noch weiter auszuführen:

Boost::Thread ist ne gute Sache und kann ich jedem empfehlen, der normale Sachen machen will.

Ich wollte aber was machen, bei dem sich rausstellt, dass man einen speziellen Scheduler braucht. Da boost aber(so wie man sich das wünscht) hardwarelevel Threads anbietet und die vom Kernelscheduler bearbeitet werden komm ich mit boost nicht weiter.

Der Rest wurde bereits gesagt, das Thema kann man eigneltich auch schließen.

Gruß

[dv]

Boost.Asio beinhaltet eine Art Scheduler, das "io_service". Hier wird es gut erklärt: http://www.highscore.de/cpp/boost/asio.html
Das io_service beinhaltet eine Query, und kann diese parallelisiert abarbeiten. Vielleicht ist das nützlich.

[knivil]

Ich wollte aber was machen, bei dem sich rausstellt, dass man einen speziellen Scheduler braucht.

Um ehrlich zu sein: Ich habe immer noch nicht verstanden, was du eigentlich willst.

[Lord Delvin]

Hatte ich auch nicht erwähnt, aber grob:

Ich hab letztes Semester ne Vorlesung über Betriebssysteme gehört und die haben behauptet, dass man für jede SMP fähige Implementierung von Locks oder anderen Synchronisationsprimitiven (hardware) atomare Operationen braucht.
Das ist halt nicht geschickt, wenn du viele Kerne am gleichen Speicher hängen hast und du willst jetzt atomar was ändern, weil du im großen und ganzen alle Kerne dafür anhalten musst...oder so ähnlich, also in der Praxis kann man da schon noch bessere Sachen machen, aber der Overhead bleibt enorm.
Und ich hab das nicht glauben können und in der Tat ein Protokoll gefunden mit dem man mit shared memory und einem kleinen Speicheroverhead auch ohne das auskommt. Allerdings benötige ich einige zusätzliche threads UND damit das halbwegs sinnvoll läuft und auch im allgemeinen Fall noch das macht, was man erwartet, braucht man eine Methode mit der man dem Scheduler sagen kann, dass man grad blockiert ist, weil man an einem Software lock hängt. (Das wäre im zweifelsfalle einfach durch setzen eines entsprechenden bits und yield(), aber so ne funktion konnte ich nur bei userland schedulern schreiben und da bin ich dann zum Schluss gekommen, dass ich entweder mit normalen Condition Variablen die der Kernel anbietet das verhalten simuliere. Da sieht man dann zwar nicht dass es korreckt ist und es ist vermutlich auch wesentlich langsamer als es sein könnte, aber letztlich is es auch nicht so wichtig. ...keine Ahnung hab auch momentan ne größere Motivation den Rest meiner Semesterferien noch etwas zu genießen:D)

Gruß

[dv]

Klingt wie eine seltsam mutierte Version von Software Transactional Memory.

[knivil]

atomar was ändern, weil du im großen und ganzen alle Kerne dafür anhalten musst

Nein, dass muss man nicht. Nur wenn alle Kerne gleichzeitig diese atomare Operation nutzen, was selten der Fall ist.

[Lord Delvin]

Im prinzip hast du zwar recht, ABER:
Du musst diesen Fall erkennen können und damit musst du zumindest allen Kernen zuhören (können).
Und in dem Fall in dem dus nicht musst, war die synchronisation sowieso nicht sinnvoll.

Ich muss letztlich aber schon zugeben, dass es nicht soo viel bringt wie ich zunächst dachte und dass es vor allem bei der momentanen (Bus-/Speicher-)Architektur nicht viel bringt.

Gruß