Hilfe bei Atomics benötigt
-
Hallo liebe Forengemeinde,
Ich schreibe gerade einen Server mithilfe von boost.asio. Jeder Client soll eine write_line()-Funktion bekommen, die aus mehreren Threads aufgerufen werden kann. Nun ist es ja so, dass man logischerweise nicht mehrere write-Operationen gleichzeitig ausführen kann, also habe ich eine Queue für ausgehende Nachrichten pro Client. Da mein Server kein typischer "Thread/Client"-Server ist, ist diese Queue eine nicht-blockierende.
Nun muss ich dafür sorgen, dass diese Queue vollständig abgearbeitet wird, wenn einmal write_line aufgerufen wird. Hierzu habe ich einen atomic_bool pro Client, der mir angibt, ob gerade ein Thread schreibt. Wenn nun write_line aufgerufen wird, werfe ich die zu sendende Nachricht in die Queue. Falls der atomic_bool false ist, rufe ich eine Funktion auf, die so lange schreibt, bis die Queue leer ist. Somit ist sichergestellt, dass immer nur ein einziger Thread schreibt.
Mein Problem liegt jetzt genau beim atomaren prüfen und anschließenden setzen des atomic_bools. Folgendes wäre falsch, da nicht atomar:
if(!writing) { writing = true; start_write(); }Ich weiß auch, dass man das mit CAS machen kann, allerdings bietet der atomic_bool dafür zwei an: atomic_compare_exchange_strong und atomic_compare_exchange_weak. Außerdem haben beide noch einen Parameter für Memory-Order, wovon ich leider ebenfalls keine Ahnung habe.
Hier nochmal der gekürzte Code, falls etwas unverständlich war:
struct session { void write_line(std::string line) { outgoing_messages_.push(line + "\r\n"); // wie korrekt? if(!writing_) { writing_ = true; do_write(); } } private: void do_write() { // schreibe bis queue leer writing_ = false; } std::atomic_bool writing_; tbb::concurrent_queue<std::string> outgoing_messages_; };Kann mir hier jemand helfen, und sagen, wie ich das richig mache?
Grüße,
Der Kellerautomat
-
Keine Ahnung, ich Weiss nicht mal wo dein Problem liegt. Das ist alles sehr unverstaendlich ... Du schreibst also einen Server und jeder Client soll ... haeh? ich dachte wir sind beim Server ...
-
Ein Client hat auch auf dem Server ein Objekt, das ihn repäsentiert - dieses enthält unter anderem den Socket, sowie eben diese genannten Verwaltungsdaten.
-
Dafuer gibts .compare_exchange_weak/strong
fuer mich sieht das aber eher nach etwas aus das wirklich locken will.
-
Shade Of Mine schrieb:
Dafuer gibts .compare_exchange_weak/strong
Ja, aber welches davon verwende ich denn?
-
Auf x86er Hardware ist es egal.
Prinzipiell ist der Unterschied der, dass die weak Variante oefter fehlschlagen kann als die strong Variante um auf bestimmter Hardware eine effizienter Implementierung zu erlauben.
Ich verwende immer strong aber ich habe keine Argumente warum das eine oder das andere besser ist.
PS:
das sieht dennoch wie eine Situation fuer einen Mutex aus.
-
Shade Of Mine schrieb:
das sieht dennoch wie eine Situation fuer einen Mutex aus.
Wie kommst du darauf? Ich möchte nur überprüfen, ob ein Thread bereits schreibt, damit niemals zwei Threads gleichzeitig schreiben. Warum willst du da einen Mutex nehmen?
-
Kellerautomat schrieb:
Shade Of Mine schrieb:
das sieht dennoch wie eine Situation fuer einen Mutex aus.
Ich möchte nur überprüfen, ob ein Thread bereits schreibt, damit niemals zwei Threads gleichzeitig schreiben.
Wenn mich jemand fragt warum er einen Mutex verwenden soll, dann wuerde ich den Satz als Antwort gelten lassen
Ein Mutex ist dafuer da, dass ein Codeblock nicht von 2 Threads gleichzeitig ausgefuehrt werden kann. Du vergewaltigst hier atomics.
-
Lass die Finger von Threads, du tust dir damit nur heftig weh.
-
Shade Of Mine schrieb:
Ein Mutex ist dafuer da, dass ein Codeblock nicht von 2 Threads gleichzeitig ausgefuehrt werden kann.
Das mag schon sein, aber ich _kann_ und _will_ nicht warten. Mein Server verwendet einstellbar viele Threads, was bedeutet, dass ein blockierter Thread einen nicht mehr antwortenden Server zur Folge haben kann.
-
Kellerautomat schrieb:
Shade Of Mine schrieb:
Ein Mutex ist dafuer da, dass ein Codeblock nicht von 2 Threads gleichzeitig ausgefuehrt werden kann.
Das mag schon sein, aber ich _kann_ und _will_ nicht warten.
ok.
Kellerautomat schrieb:
Mein Server verwendet einstellbar viele Threads, was bedeutet, dass ein blockierter Thread einen nicht mehr antwortenden Server zur Folge haben kann.
Ich verstehe nicht, wie das eine das andere implizieren soll. Kannst du das näher erläutern?
-
Okay, kleines Beispiel (es handelt sich um einen Chatserver, ähnlich IRC): User X befindet sich in Channel Y. Nun verlässt User A den Channel, User B joint, User C schreibt eine Nachricht in den Channel und User D schreibt X im Query an. Wenn eine der Operationen unerwartet lange blockiert, sind alle anderen Threads auch blockiert.
-
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?