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

fuer mich sieht das aber eher nach etwas aus das wirklich locken will.

Dafuer gibts .compare_exchange_weak/strong

Ja, aber welches davon verwende ich denn?

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.

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?

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.

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.

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?

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.

Wenn eine der Operationen unerwartet lange blockiert, sind alle anderen Threads auch blockiert.

Welche Operation?

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.

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

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.

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

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.