Alternative zu Boost.Thread
-
Abend zusammen!
Kennt Ihr zufällig eine nützliche Alternative zur Thread-Bibliothek von Boost?
Der Grund für meine Frage ist Folgender:
Ich benötige dringendst sowohl MutexLock-Objekte als auch Semaphore. Nach den Angaben eines der Projektmitglieder der Boost-Library wurde unglücklicherweise das Semaphore aus der Bibliothek entfernt. Hat angeblich nicht so richtig funktioniert. Toll!
Jetzt bliebe mir dann nur noch entweder Marke Eigenbau übrig ( nur wie schreib ich am beste ein plattformunabhängiges Semaphore mit C ? - unter Java kein Problem! ) oder ich steig auf eine andere Threading-Bibliothek um! Nur welche?Wäre schön, wenn Ihr mir weiterhelfen könntet!
Danke!
Grüße,
TS++
-
es gibt ja noch die SDL
btw, mutex kenn ich, aber was ist Semaphore ?
-
Servus!
Ein Semaphore ist eine spezielle Variante einer Sperrvariablen (1968 von Dijkstra eingeführt).
Im Gegensatz zu den Lock/Mutex Objekten besitzen Semaphore einen internen Zähler. Solange dieser Zähler > 0 ist, wird er bei jedem Aufruf von acquire() um 1 dekrementiert. Hat der Zähler den Wert 0, wird der aufrufende Thread schlafen geschickt. Bei jedem Aufruf von release() wird der Zähler dann wieder um 1 inkrementiert. Wartende Threads werden grundsätzlich immer dann vom BS aufgeweckt, sobald ein aktiver Thread release() aufgerufen hat.Man könnte somit relativ leicht ein MutexLock durch Ableiten von einem solchen Semaphore erzeugen. Ein MutexLock ist nähmlich nichts weiter als ein Semaphore mit dem internen Zähler = 1.
Mit MutexLock und Semaphore in Kombination kann man spezielle Standardprobleme beim Threading relativ bequem lösen. (z.B. das Erzeuger-Verbraucher-Problem)
Und wie bereits erwähnt, unter Java können Semaphore relativ leicht realisiert werden. Ich verwende zu diesem Zweck nichts weiter als das Monitorkonzept von Java (synchronized) und die beiden Routinen wait() und notify().
Nur wie ich sowas unter C schreiben soll???Grüße,
TS++
-
Hallo,
spontan fallen mir da ACE und JTC sein. Oder halt einfach PThreads.
-
Morgen!
HumeSikkins, danke für deine Antwort!
Ich schau mir die 3 Ansätze mal an.Ursprünglich hab ich sogar daran gedacht C++ und Java zu diesem Zweck zu kombinieren. Das grundlegende Threading-Problem hätte man wahrscheinlich auch über JNI lösen können. Nur eben mit relativ viel Aufwand. Außerdem stößt man, wenn man den Ansatz mal weiterspinnt, früher oder später auf weitere Barrieren, die man hauptsächlich Java zu verdanken hat. Ich hätte quasi von der Java-Seite aus nicht die C++-Objekte selbst, sondern nur den JNI-Zugriff auf diese (mit ner Wrapper-Klasse) abgesichert. Hätte sogar funktioniert!
Aber es ist und bleibt nunmal lediglich eine Absicherung der JNI-Schnittstelle und nicht direkt der C++-Objekte, die über die Schnittstelle ferngesteuert werden!:(Mal schaun, ob ich mit den 3 o.g. Ansätzen das Problem doch rein in C++ schreiben kann!
Grüße,
TS++