Die Tücken der parallelen Programmierung

[Sculletto]

Ob Du die Unterteilung nach Gleisen oder nach Gleisabschnitten hast, ist letztlich egal.

im Semaphor-Fall gibt es aber gar keine Unterteilung, weder nach Gleisen noch nach Abschnitten, sondern ein einziges Gleis, an dem es nichts zu unterteilen gäbe.

Wenn Du sie alle miteinander kommunizieren lassen willst, werden es eben entsprechend mehr. Aber wozu?

damit sie sich synchronisieren können. So dass jeder Thread erst dann mit seinem dunkelgrünen Abschnitt anfängt, wenn alle anderen Threads mit ihren hellgrünen Abschnitten fertig sind.

Eben, es ist doch egal, wofür etwas ursprünglich kozipiert worden sein mag, wichtig ist doch, was, man damit alles machen kann.

das wird aber nicht selten dadurch bestimmt, wofür es ursprünglich konzipiert wurde. Fakt ist, man kann mit einem Semaphor nicht machen, was ich benötige.

Das die Art der Synchronisation letztendlich Deiner jetzigen Variante ähneln würde, liegt in der Natur der Sache

dass sich an der Synchronisation selbst nichts ändern würde, wenn ich Semaphore statt Boost-Mutexes und -Locks verwenden würde, liegt schlicht daran, dass die Synchronisation selbst damit gar nicht gemacht wird. Die Synchronisation wird durch die Condition-Variablen aka Monitore realisiert. Der Mutex und die Locks dienen nur als Hilfsmittel, einmal weil boost::condition_variable::wait() einen Lock als Parameter verlangt, und andererseits um den Zugriff auf die Zähler threadsicher zu machen.

Da liegt dann wohl eher das Problem.

es liegt nicht, es lag. Ich habe es ja gelöst.

Wobei ich netyt erst überlegen müsste, wie man es "versehentlich" so programmiert, dass ein Thread trotz Schnittstelle zeitweise keine Signale empfängt, bzw. diese sogar im Nirwana verschwinden.

das steht in meinem Eingangspost. Ich zitiere noch einmal die betreffende Stelle:

Es zeigte sich nämlich, dass es ab und zu mal vorkam, dass in dem Augenblick, in dem der Haupthread das Start-Signal sendete (dunkel orange im Diagramm), gar nicht alle Worker-Threads bereit waren, das Signal entgegenzunehmen. Konsequenz: der Hauptthread hatte das Signal abgeschickt und wartete darauf, dass die Worker-Threads fertig wurden, aber einer der Worker-Threads hatte das Signal nicht empfangen und wartete noch auf dieses.

Meine Rede. Wieso Du immer daran denkst alle miteinander kommuniyieren lassen zu müssen, nur weil die Art der Kommunikation sich ändert,

ich denke nicht deswegen daran, alle miteinander kommunizieren lassen zu müssen, weil sich irgendeine Art der Kommunikation ändern würde, sondern deswegen, weil sie sich synchronisieren müssen (helle orange Balken im Diagramm).

Vielleicht weil es bei dieser Art sonst i.a. so umgesetzt wird oder weil es in irgendeiner Spezifikation bzw. dem typischhen Programmierbeispiel so steht?

zu meinem Vorhaben kenne ich weder eine Spezifikation noch ein typisches Programmierbeispiel. Ich habe vor Jahren mal mal ein einzelnes Beispiel zu einer ähnlichen Problemstellung gefunden, das würde ich allerdings nicht als typisch bezeichnen. Da konnte ich aber nur feststellen, dass es dort genauso gemacht wurde, wie ich es mir bereits ausgedacht hatte. Nur lag da halt der Schwerpunkt auf der Synchronisation der Worker-Threads untereinander, die Synchronisation mit dem Hauptthread zwecks grafischer Ausgabe wurde da AFAIR nicht behandelt.