Synchronisation von Zugriffen von 2 Threads auf eine Queue

Schamote

Hallo,

ich habe zwei std::threads von denen einer nur in eine std::queue pusht und der andere ausschließlich aus der queue popt, wenn Element enthalten sind.
Somit ruft der "pusher" nur push_back() auf und der "popper" ruft nur size(), front() und pop() auf.
Muss ich die beiden threads mit z.B. einem mutex sychronisieren oder ist das nicht notwendig?
Ich habe danach gegooglet, allerdings findet man dort nur Antworten auf Senarios, in denen es entweder mehrere Schreiber bzw. Leser oder beides gibt, wo allerdings häufig nur die Leser untereinander und die Schreiber untereinander synchronisiert werden. Deswegen frage ich mich gerade, ob ich dann überhaupt mich darum kümmern muss, oder ob ich das einfach überspringen kann.

Danke!

TyRoXx

Schamote schrieb:

Muss ich die beiden threads mit z.B. einem mutex sychronisieren

Ja

hustbaer

@Schamote
Nur Leser müssen nicht synchronisiert werden. Dann darf es aber überhaupt gar keine Schreiber geben.

Sobald es Schreiber gibt musst du synchronisieren, und dann natürlich überall, auch bei den Lesezugriffen.

Welche Funktionen dabei genau aufgerufen werden ist irrelevant. Interessant ist nur ob die Funktionen const sind (=lesen) oder nicht (=schreiben).

Und BTW: beide deiner Threads sind Schreiber was die Queue betrifft, denn pop() ist ganz klar eine Schreiboperation.

Der Begriff "schreiben" ist hier wohl ungünstig, da verwirrend. Ob ein neues Element in die Queue "geschrieben" wird ist egal. Die Frage ist ob die Queue modifiziert wird. Und dann sollte klar sein, dass auch pop() als "schreiben" gilt, da es ja wohl eindeutig die Queue modifiziert.

Eisflamme

Alternativ gibt es auch lockfree queue, da braucht man dann nicht mehr synchronisieren: http://www.boost.org/doc/libs/1_56_0/doc/html/lockfree.html

Schamote

Danke für die Antworten.

Darauf, dass die beide schreibend zugreifen, hätte ich auch selber kommen können

Ich schaue mich dann nochmal um bezüglich den verschiedenen Queue Ausführungen die es so alle gibt, single-producer/single-consumer scheint auch in die Richtung zu gehen.