Verteilen von Daten zwischen mehreren Threads



  • Hi,
    ich muss unter Clients einer multithread Server Instanz einen data stream verteilen der nicht verändert wird. Das heißt ich habe einen Thread aus dem die Daten kommen und alle anderen Threads sollen diese Daten nur lesen müssen (sie müssen sie nicht mehr verändern) damit sie die Daten zu den clients schicken können.

    Ich habe es mit einer thread safe queue(https://blog.chrisd.info/a-simple-thread-safe-queue-for-use-in-multi-threaded-c-applications/) versucht aber sobald ich es mit mehr als einen client versucht habe hat nur noch der 2 bzw. der neue die Daten erhalten.

    Wie löse ich das Problem, gibt es thread safe queues die das können oder macht man das anders?

    mfg Luick



  • Wie wärs mit std::async und std::shared_future<>?



  • Ich glaube du müsstest dein Problem hier noch etwas detaillierter beschreiben. Bekommen immer alle Clients alle Responses, oder hat jeder Client eine spezifische Anfrage und bekommt eine spezifische Antwort? In dem Fall braucht jeder Client für die Antwort eine eigene Q. Du kannst das natürlich auch über CriticalSections lösen, die ein Datenobjekt "schützen", in das der "Verarbeiter" die Response reinschreibt und der Client das Ding pollt. Diese Lösung aber eher nicht so elegant.


  • Gesperrt

    Du könntest UDP-Sockets verwenden. Ein Sender und multiple Empfänger sind dabei ganz normal. Das funktioniert auch lokal, aber eben auch über's Netz.



  • Hört sich nach extrem viel Overhead an.



  • @mrgrimod
    Ich glaube die Variante die @It0101 vorgeschlagen ist gar nicht blöd. Jeder Client erzeugt seine eigene (threadsichere) Queue, und registriert diese beim Erzeuger. Beim Einfügen in die Queue kann der Erzeuger (oder die Queue) dann sehr einfach kontrollieren was passieren soll wenn die Queue eines Clients "übergeht".

    Alternativ könnte man eine gemeinsame Queue machen, in der die Nachrichten eine fortlaufende Nummer verpasst bekommen. Jeder Client muss sich dann die Nummer der letzten Nachricht merken die er gelesen hat, und dann immer wieder bei der Queue nachfragen ob es Nachrichten mit einer höheren Nummer gibt. Ist aber vermutlich fummeliger zu implementieren.



  • Wenn der Client einer von der Sorte ist, der nur einen Request versendet und nach erhalten der Response direkt wieder stirbt, könnte man sich sogar die Q am Client sparen und dort nur ein geschütztes Objekt anlegen, in das der Verarbeiter-Thread dann die Response packt. Oder wahlweise ein std::atomic oder artverwandte Strukturen. Je nachdem woraus die Response besteht.


Anmelden zum Antworten