Hilfe bei Atomics benötigt
-
Wenn nur ein Thread schreiben kann, dann musst du blockieren. Denkst du mit atomics gehts schneller?
Du koenntest einfach feiner locken. zB private Messages blockieren nicht den Main Channel und so.
Aber atomics haben hier nichts zusuchen und zwar rein garnichts.
-
Kellerautomat schrieb:
Wenn eine der Operationen unerwartet lange blockiert, sind alle anderen Threads auch blockiert.
Welche Operation?
-
Schreiben am Socket des Users X.
-
Kellerautomat schrieb:
Schreiben am Socket des Users X.
Dann brauchst du einen Mutex der diese eine Operation lockt.
Fertig.
User Y ist davon nicht betroffen.PS:
du kannst gerne mal alles genauer erklaeren. Dann koennen wir dir sicher besser helfen.
-
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