ich brauche Multithreading für ein in Kürze anstehendes Projekt und habe mich daher ein bisschen darin eingelesen.

Im Grunde muss das Programm vier Aufgaben bewältigen:

Daten einlesen, verarbeiten, Daten ausgeben und dem Benutzer eine Oberfläche bieten.
Ich dachte mir nun, dass es wohl das beste wäre das ganze in vier Threads aufzuteilen.

Aber mit welchem fange ich an?
Soll der Benutzeroberflächen-Thread alle anderen (drei) starten?
Oder sollte ich einen fünften Thread erstellen, der nur dazu dient die anderen (vier) zu verwalten?

Wie muss man sowas aufbauen?

LG
Sinthoras

Hm, nach Möglichkeit sollte das alles so ziemlich in Echtzeit ablaufen (Einlesen, Verarbeiten, Ausgeben) und ich dachte, man könnte es auf die Art etwas beschleunigen?!?

Das "Einlesen" geschieht in diesem Fall nämlich nicht einfach aus einer Textdatei o.ä., sondern von einer Kamera. Außerdem müssen die Bilder vor der Verarbeitung noch zerschnitten werden.
Es kommen dabei immer neue Bilder an, die möglichst schnell zerschnitten und verarbeitet werden müssen.

Die Ausgabe könnte man wohl wirklich direkt in die Verarbeitung einbauen, aber ich dachte, bei der ganze Arbeit, die mit dem Einlesen verbunden ist, dem einen eigenen Thread zu gönnen, oder nicht?

Zur Frage "5. Thread ja/nein": nein. Lass den UI Thread die anderen Starten. Soll dein Programm auch "command line" Fähig sein bzw. mal als Service laufen, kann der UI Thread immer noch alle anderen rausstarten, und dann einfach nixmehr tun ausser auf eventuelle service-control-messages zu reagieren.

Zum Rest: ich denke es macht dann Sinn es in mehrere Threads aufzuteilen wenn das Einlesen synchron passiert. Am einfachsten wird es wohl sein wenn du eine Art Filterkette bastelst, wobei Einlesen, Zerschneiden, Verarbeiten und Output die Filter sind. Dann kannst du jeden Filter intern so implementieren wie du möchtest, also mit eigenem Thread oder ohne.

Ein weiterer Grund mehrere Threads zu verwenden wäre wenn es mehrere Verarbeitungsschritte gibt die parallel erfolgen können und merklich Rechenzeit benötigen (da aktuelle CPUs 2-4 Cores haben können diese Verarbeitungsschritte dann auch wirklich parallel laufen). Also z.B. wenn das "Zerschneiden" ein aufwändiger Vorgang ist zahlt es sich aus, wenn das in ein paar Mikrosekunden/Bild erlidigt ist zahlt sich dafür kein eigener Thread aus.

Für die Implementierung mit einem eigenen Thread bietet sich eine bounded FIFO Queue an, da kannst du die Daten von einem Thread aus reinstecken, und von einem anderen aus auslesen. "bounded" heisst dabei dass du eine Obergrenze festlegst wie viel Daten maximal gepuffert sein können (z.B. nur max. 1 Bild oder auch max. 3 Bilder).

Allerdings solltest du dir die Frage stellen was wichtiger ist: hoher Throughput (viele Bilder pro Sekunde) oder niedrige Latenz (geringe Zeit vom Einlesen des Bildes bis zur fertig verarbeiteten Ausgabe).
Für hohen Throughput eignet sich die Lösung mit mehreren Threads gut, dafür hast du u.U. mehr Latenz als mit nur einem Thread.
Für geringe Latenz bringt es dagegen nix, da wäre eher eine Lösung mit nur einem einzigen Thread angebracht, dafür musst du u.U. mehr Frames droppen als mit mehreren Threads.

Nochwas: wenn das ganze auf einer Single-Core CPU laufen soll sind natürlich nur Stellen interessant wo du auf irgendetwas warten musst was nicht "Datenverarbeitung mit der CPU" ist, also z.B. auf das nächste Bild von der Kamera oder auf das Schreiben in ein File. Diese Teile sollte man vom Rest "entkoppeln", also in einen eigenen Thread steckten oder über asynchrone APIs erledigen. Alles andere kann dann sequentiell in einem Thread laufen, mehrere Thread die bloss "rechnen" bringen da nix, weil nix parallelisiert werden kann.

Im Grunde muss das Programm vier Aufgaben bewältigen:

Daten einlesen, verarbeiten, Daten ausgeben und dem Benutzer eine Oberfläche bieten.

ROFL, welches Programm macht den irgendwas anderes?

Im Grunde muss das Programm vier Aufgaben bewältigen:

Daten einlesen, verarbeiten, Daten ausgeben und dem Benutzer eine Oberfläche bieten.

ROFL, welches Programm macht den irgendwas anderes?

Lies die Beiträge zu Ende.
Es ist noch genau genug erläutert.

Ich gebe zu, dass das zu Anfang unglücklich formuliert war, aber wenn du einfach mal weiter gelesen hättest, wäre uns sowas erspart geblieben.

hustbaer schrieb:

@Sinthoras:

Zur Frage "5. Thread ja/nein": nein. Lass den UI Thread die anderen Starten. Soll dein Programm auch "command line" Fähig sein bzw. mal als Service laufen, kann der UI Thread immer noch alle anderen rausstarten, und dann einfach nixmehr tun ausser auf eventuelle service-control-messages zu reagieren.

Danke, dann lass ich das.

hustbaer schrieb:

@Sinthoras:
Zum Rest: ich denke es macht dann Sinn es in mehrere Threads aufzuteilen wenn das Einlesen synchron passiert.

Ja, das soll es.

Wie aufwendendig das Zerschneiden sein wird, weiß ich noch nicht genau, jedenfalls wird der Einlesethread ja auf die Kamera warten müssen und währenddessen kann der Rest ja weiterarbeiten.

Das fertige Programm wird auf einem Dualcore laufen, also lohnt sich das Aufteilen der "Datenverarbeitung mit der CPU" wohl schon. Danke.

Für die Implementierung mit einem eigenen Thread bietet sich eine bounded FIFO Queue an, da kannst du die Daten von einem Thread aus reinstecken, und von einem anderen aus auslesen. "bounded" heisst dabei dass du eine Obergrenze festlegst wie viel Daten maximal gepuffert sein können (z.B. nur max. 1 Bild oder auch max. 3 Bilder).

Vielen Dank, das ist eine wirklich gute Idee!
Bis auf die Ausgabe lässt sich das wohl so machen (die nämlich arbeitet nicht mehr mit den Bildern).

Zum letzten Abschnitt: Eine geringe Latenz ist leider auch nicht ganz unwichtig.
Kann ich es irgendwie so lösen, dass im Notfall der Bildverarbeitung mehr Rechenzeit zugeteilt wird, als dem Einlesen?

Das wäre doch bei mehreren Threads (wenn ich es richtig verstehe) das Problem, dass z.B. der Einlese-Thread der Verarbeitung Rechenzeit klaut, weshalb das einzelne Bild dann länger in der Verarbeitungskette rumdümpelt, oder nicht?

Ideal wäre es ja wohl, wenn ein Kern die ganze Zeit nichts anderes machen würde, als Rechen (die Verarbeitung erledigen), während der andere sich um den "Rest" kümmert... keine Ahnung, ob sowas möglich ist...

Soweit jedenfalls schonmal vielen Dank.

DEvent schrieb:

Im Grunde muss das Programm vier Aufgaben bewältigen:

Daten einlesen, verarbeiten, Daten ausgeben und dem Benutzer eine Oberfläche bieten.

ROFL, welches Programm macht den irgendwas anderes?

Lies die Beiträge zu Ende.
Es ist noch genau genug erläutert.

Ich gebe zu, dass das zu Anfang unglücklich formuliert war, aber wenn du einfach mal weiter gelesen hättest, wäre uns sowas erspart geblieben.

Wieso hast du das nicht gleich gemacht? So wars total nichtssagend.

Können wir jetzt bitte zum eigentlichen Thema zurückkommen?

Ich habe meinen Fehler doch eingestanden - reicht das denn nicht?

Können wir jetzt bitte zum eigentlichen Thema zurückkommen?

Sorry, ich fand das nur unglaublich Witzig, weil das ja im ersten post stand. Sollte auch nicht abwertend sein, war einfach nur witzig.

Ich wollte nur jetzt gerne zum Thema zurückkommen und nicht weiter über den einen Satz diskutieren, das wollte ich damit bezwecken.

Zum letzten Abschnitt: Eine geringe Latenz ist leider auch nicht ganz unwichtig.
Kann ich es irgendwie so lösen, dass im Notfall der Bildverarbeitung mehr Rechenzeit zugeteilt wird, als dem Einlesen?

Ja, das passiert "automatisch" wenn du eine bounded Queue verwendest - zumindest wenn der "Insert" Aufruf blockiert (siehe weiter unten). Wenn "das Einlesen" schon "weiter vorne" ist als "die Bildverarbeitung", dann wird die Queue zwischen "Einlesen" und "Bildverarbeitung" automatisch "voll". Wie "voll" eben "voll" ist kannst du ja selbst definieren (max. 1 Bild, max. 2 Bilder etc.).

Wenn das passiert, also die Queue "voll" wird kann man 3 Dinge tun:

1. die Queue blockiert den "Insert" Aufruf - der Einlese-Thread muss also so lange warten bis der Bildverarbeitungs-Thread das Bild komplett verarbeitet hat an dem er gerade arbeitet. Dadurch sparst du Rechenzeit beim Einlesen, da der blockierte Thread kaum Rechenzeit braucht.

2. die Queue lässt den "Insert" Aufruf einfach fehlschlagen, und das neu einzufügende Bild wird verworfen. Der Einlese-Thread kann sofort weitermachen und ein neues Bild holen. Dadurch wird zwar ein Bild verworfen ("dropped frame"), allerdings ist das nächste Bild welches in die Queue eingefügt wird (wenn sie irgendwann mal "nicht-voll" wird) "akuteller" - es sinkt also die Latenzzeit.

3. die "Queue" verwirft das zuletzt eingefügte Bild, und ersetzt es durch das neue. Der Einlese-Thread kann auch sofort weitermachen. Weiterer Vorteil: das nächste Bild welches verarbeitet wird ist nicht das (ältere) Bild das zuvor in der Queue gepuffert war, sondern das "neuere" Bild (das ältere wurde ja "überschrieben"). Die Latenzeit sinkt dadurch nochmals.

Eine maximale Queue-Länge von 1 mit Möglichkeit 3 von oben kombiniert sollte die geringst-mögliche Latenz bringen, ausgenommen eben der "mach alles in einem Thread" Variante, die aber u.U. zu wesentlich mehr dropped Frames führen könnte (da sie nur einen Core verwendet und nichts parallelisieren kann).

Wenn die "Bearbeitungszeiten" für ein Bild nicht sehr stark schwanken sollte eine maximale Queue-Länge von 1 auch ausreichend sein um maximalen Throughput (geringste "dropped frames" Rate) zu bekommen. Schwanken die "Bearbeitungszeiten" sehr stark könnte es etwas bringen eine längere Queue zu verwenden, allerdings geht das dann auf Kosten der maximalen Latenz.

Eine Aufteilung auf verschiedene Threads zwischen verschiedenen Teilen der "Bearbeitung" (also eben z.B. "Zerschneiden" und "Weiterverarbeiten") ist IMO sinnvoll, wenn diese Schritte "aufwändig genug" sind, und eben mehr als 1 Core zur Verfügung steht.
Die Queues zwischen den einzelnen Verarbeitungsschritten sollte IMO immer blockierend sein (also Möglichkeit 1 von oben), da man sonst in der ganzen Kette vor der Queue sinnlos Rechenzeit verblasen lässt. Im Prinzip trifft das auf das Einlesen eines Bildes auch zu, bloss gehe ich davon aus dass das Einlesen nicht wirklich sehr viel CPU Leistung verbrauchen wird. Normalerweise sollte das über die Grafikkarte/Capturekarte und DMA/Bus-Master passieren, plus eventuell noch einem dummen Mem-Copy. Nichst was man "sich nicht leisten könnte" quasi.

Bis auf die Ausgabe lässt sich das wohl so machen (die nämlich arbeitet nicht mehr mit den Bildern).

Auch die Ausgabe lässt sich so machen. Der letzte Verarbeitungsschritt hat ja dann nicht ein Bild als Output, sondern eben was auch immer in der Ausgabe ausgegeben wird. Die Queue zwischen dem letzten Verarbeitungsschritt und der Ausgabe ist dementsprechend keine Queue<Bild> sondern eine Queue<AusgabeDatenTypDings>.

----

Was die Latenz angeht... scchwierig abzuschätzen. Probier es aus.
Auf jeden Fall musst du wissen was du im "worst case" willst, also dann wenn die CPU Leistung nichtmehr ausreicht um alle Bilder zu verarbeiten so schnell wie sie hereinkommen.

Wenn es viel viel wichtiger ist möglichst wenig Frames zu verlieren: alles in eigenen Threads + längere Queues + alles blockierende Queues.

Wenn "beides irgendwie wichtig ist": rechenaufwändige Verarbeitungsschritte in eigenen Threads (kleine zu dem benachbarten Schritt dazu der weniger rechenaufwändig ist), Queue-Länge 1, erste Queue = "überscchreiben", alle weiteren = "blockieren".

Wenn es viel viel wichtiger ist möglichst geringe Latenz zu haben: alles in einem einzigen Thread.

----

Eine "beides ist immer ganz ganz wichtig" Lösung gibt es nicht, ausser du schaffst entsprehend schnelle Hardware an die immer "mitkommt". Dann ist es aber ziemlich egal wie du es programmierst

Wenn es irgendwann demnächst an die konkrete Umsetzung geht und noch Fragen auftauchen, melde ich mich wieder.

Vielen Dank nochmals,
Sinthoras

edit: hatte hustbaer ja auch schon erläutert.