Hilfe bei Atomics benötigt
-
Hab mal ein kleines ASCII-Art geschnitzt.
t1 t2 t3 t4 +------------------+------------------+-----------------+-------------------+ | liest Quit von A | liest Join von B | liest Msg von C | liest Query von D | +------------------+------------------+-----------------+-------------------+ | | | | | | | | | | warten warten | | | +-------> +---+ <--------+ | +------------------------> | X | <-------------------------+ informiert X, dauert lange +---+ warten
-
Wie stellst du dir das mit atomics vor dass dort kein Warten mehr stattfindet?
-
Ich werfe die anderen 3 Nachrichten in die Queue. Der Thread, der gerade an X sendet, bearbeitet dann diese weiteren 3 Nachrichten danach, während die anderen 3 Threads bereits wieder etwas anderes machen können.
-
Kellerautomat schrieb:
Ich werfe die anderen 3 Nachrichten in die Queue. Der Thread, der gerade an X sendet, bearbeitet dann diese weiteren 3 Nachrichten danach, während die anderen 3 Threads bereits wieder etwas anderes machen können.
Aha. Also benötigt die Socketoperation gar keinen Mutex, nur der Zugriff auf die Queue synchronisiert werden. Dass kann nat. curch eine lockfreie Implementation geschehen, aber auch durch mutex. Jedenfalls sind Operationen auf einer Queue grundsätzlich nicht blockierend.
Warum meinst du, die eigentliche Socket-Operation mit einem Mutex schützen zu müssen, darauf aber bei atomics verzichten zu können?
-
Ich habe da doch nirgens Mutexe. Die wollte SoM mir einreden.
-
Kellerautomat schrieb:
Ich habe da doch nirgens Mutexe. Die wollte SoM mir einreden.
OK.
Wozu brauchst du hier atomics? Was erreichst du mit der Variable "writing"?PS:
deshalb auch meine Bitte das ganze ordentlich aufzuzeichnen und nicht nur 3 Satz Posting zu machen
-
Man könnte sagen, der Wert der Variable besagt, ob gerade ein Thread den Socket besitzt. Sprich:
false -> Ich bin derjenige, der selbst schreiben muss.
true -> Ein anderer schreibt gerade, ich kann das schreiben meiner Nachricht einfach an ihn delegieren.
-
OK, das musst du mehr erklaeren. Du sharest sockets zwischen mehreren threads?
-
Nein, eben nicht. Genau das verhindere ich doch mit der Variable.
-
Kellerautomat schrieb:
Nein, eben nicht. Genau das verhindere ich doch mit der Variable.
Du musst mehr erklaeren. Das was ich bisjetzt verstanden habe klingt furchtbar konfus. Bitte skizziere dein Design hier auf.
Denn entweder verstehe ich dich nicht richtig oder mit deinem Design hats was gravierendes.
-
Uff. Ich weiß wirklich nicht, wie ich das skizzieren soll, oder was überhaupt. Ich versuche mal, den Ablauf Schritt für Schritt zu erklären.
Logischerweise darf nur ein Thread an einem Socket schreiben. Diesen nenne ich im folgenden den Besitzer des Sockets.
Nun kommen mehrere Threads an der Funktion write_line an. Irgendwie muss entschieden werden, wer der Besitzer wird und andere Threads müssen darüber informiert werden, dass es einen Besitzer gibt. Dazu überprüft jeder Thread die Variable writing und setzt sie atomar auf true, wenn sie false ist. Der schnellste Thread übernimmt also den Besitz. Dieser Thread beginnt mit dem schreiben seiner eigenen Nachricht und danach schreibt er alle anderen Nachrichten aus der Queue, bis diese leer ist.
Für alle anderen Threads schlägt diese Operation fehl. Sie werfen ihre Nachrichten nur in die Queue hinein und delegieren damit das Schreiben an den besitzenden Thread.
-
Warum hast du mehrere Threads?
Warum ist das nicht schon von vornherein definiert wer Schreiben darf und wer in die Queue wirft?
-
Shade Of Mine schrieb:
Warum hast du mehrere Threads?
Weil da das Problem ein noch viel größeres wäre. Wenn nur irgendwas blockiert, ist der Server lahmgelegt. Davon abgesehen: Skalierbarkeit.
Shade Of Mine schrieb:
Warum ist das nicht schon von vornherein definiert wer Schreiben darf und wer in die Queue wirft?
boost.asio wählt die Handler-Threads auf eine unbekannte Weise aus, ich nenne es mal zufällig. Wüsste nicht, warum oder wie ich da einen Besitzer festlegen könnte/sollte. Jeder Thread könnte an jeden User eine Nachricht senden müssen.
-
wenn du eh eine Queue für zu versendende Nachrichten hast, wieso stellst du nicht einen Thread rein für das Schreiben ab und die restlichen Threads pushen nur ihre Nachrichten in die Queue.
Aber wiso hast du nur einen Socket? AFAIK existiert auf Serverseite für jeden Netzwerkclient ein eigener Socket (z.b. unter POSIX/Linux liefert accept diesen socket zurück)
Und ich vermute das es in boost.asio auch nicht anders ist.
-
Du hast meine Frage nicht beantwortet.
Mich interessieren keine Implementierungsdetails
Ich will wissen warum du mehrere Threads hast.PS:
Dein Design ist ungewoehnlich. Deshalb musst du jetzt entweder darauf vertrauen dass du alles richtig gemacht hast oder hier dein Design skizzieren. Sonst fuehrt das hier zu nichts.
-
Ach ja in der boost.asio Dokumentation gibt es auch ein chat example
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html
-
@firefly: Natürlich hab ich pro Client einen Socket (+ eine Queue + den atomic_bool).
@SoM: Du sagst einerseits, Implementierungsdetails interessieren dich nicht, andererseits möchtest du, dass ich das Design skizziere. Was genau willst du sehen?
-
Design != Implementierungsdetails *g*
Aber dann gibt es doch kein synchronistationsproblem beim Schreiben auf den Socket. Das einzige was du synchronisieren musst ist der Zugriff auf die Queue. Und zwar wenn von einem Client eine Nachricht an einen anderen Client geschickt werden soll. (Der Serverpart von Client A packt die Nachricht an Client B in dessen Queue auf Serverseite)
-
Ich habe ja auch nicht gesagt, dass es ein Synchronisierungsproblem auf den Sockets gibt. Das ist durch die Besitzerwahl bereits ausgeschlossen.
Die Queue ist eine tbb::concurrent_queue aus den Intel Thread Building Blocks und damit bereits thread-safe.
-
@SoM:
Der Server hat:
- Einen Acceptor zum annehmen von Verbindungen sowie einen accept-handler, der die Clients konstruiert und in eine Liste reinwirft.
- Die Clientliste
- Einen Threadpool
- Einen Handler für ClientnachrichtenEin Client hat:
- Einen Socket, die Message-Queue für ausgehende Nachrichten, sowie den atomic_bool für die Besitzerwahl
- Einen handler für gelesene Nachrichten, der wiederum den Handler am Server aufruft
- Einen write-handler, der aufgerufen wird, sobald eine Nachricht vollständig geschrieben wurde
- Die Funktion, um eine Nachricht zu sendenserver client +--------------------+ +---------------+ | accept-handler | | socket | | acceptor | | writing-bool | | thread-pool | | message-queue | | clients | | write-handler | | client-msg-handler | | read-handler | +--------------------+ | write-line | +---------------+Wenn es das nicht ist, was du hören wolltest, dann erklärs mir bitte.