boost::asio::io_service::strand

314159265358979

Ich weiß schon. Deshalb schreibe ich auch thread-safe Code. Damit ich keine Beschränkung auf 1 Handler habe. Deshalb benutze ich strand auch nicht.

Tachyon

314159265358979 schrieb:

Ich weiß schon.

Du weißt offensichtlich nichts...

314159265358979 schrieb:

Deshalb schreibe ich auch thread-safe Code*. Damit ich keine Beschränkung auf 1 Handler habe*. Deshalb benutze ich strand auch nicht.

[] Du hast verstanden, was ich geschrieben habe.

314159265358979

Offenbar haben wir ein Kommunikationsproblem.

Erkläre doch mal anders, was du mir sagen willst.

ipsec

314159265358979 schrieb:

Ich weiß schon. Deshalb schreibe ich auch thread-safe Code. Damit ich keine Beschränkung auf 1 Handler habe. Deshalb benutze ich strand auch nicht.

Schonmal daran gedacht, dass der Strand effizienter implementiert werden kann als ein Mutex? Bleiben wir bei dem Beispiel, dass der Connect-Handler synchronisiert werden muss. Nehmen wir an, du hast einen Threadpool mit 4 Threads und benutzt einen Mutex. Wenn sich jetzt gleichzeitig 4 Clients connecten, kann es passieren, dass der Handler in je einem Thread gespawnt wird und dass 3 Handler warten, womit im Endeffekt für kurze Zeit alle Threads blockiert wären.
Wenn du aber einen Strand benutzt, „weiß“ der ioservice, dass der Connect-Handler nicht mehrmals laufen darf und würde ihn gar nicht mehrmals starten. In unserem Beispiel wären also noch 3 Threads frei für andere Handler.

314159265358979

Deshalb hält man die Kreuzungspunkte so klein wie möglich. Das dürfte in fast jeden Fall besser sein.

ipsec

314159265358979 schrieb:

Deshalb hält man die Kreuzungspunkte so klein wie möglich. Das dürfte in fast jeden Fall besser sein.

Bitte? Welche Kreuzungspunkte? Ganz ohne Synchronisation wirst du nicht auskommen.

Tachyon

314159265358979 schrieb:

Deshalb hält man die Kreuzungspunkte so klein wie möglich. Das dürfte in fast jeden Fall besser sein.

Wenn Du keinen Kreuzungspunkt willst/brauchst, dann benutzt Du für den entsprechenen Handler keinen Strand.

[]Du hast strands verstanden
[x]Du solltest die Finger von boost.asio lassen.

314159265358979

Okay, ich drücke es nochmal anders aus: Man versucht, die Zeit, in der synchronisiert werden muss, möglichst klein zu halten. Kleines Beispiel, direkt aus meinem IRC-Bot Projekt entnommen.

Eine map soll geleert werden in Thread A Hier muss auch noch auf jedes Objekt eine Funktion func aufgerufen werden. Thread B möchte etwas einfügen.

Der ineffiziente Weg:

{
    lock_t lock(mtx);
    for(jedes element in map)
        elem.func();

    map.clear();
}

Der bessere Weg:

map tmp;
{
    lock_t lock(mtx);
    tmp = move(map);
}

for(jedes element in tmp)
    elem.func();

// Edit: Destruktor räumt hier ja automatisch auf.

Tachyon

314159265358979 schrieb:

Der bessere Weg:

map tmp;
{
    lock_t lock(mtx);
    tmp = move(map);
}

for(jedes element in tmp)
    elem.func();

// Edit: Destruktor räumt hier ja automatisch auf.

Äh ja. Ich glaube, es gibt kein denkbares Szenario, wo das irgendetwas bringt.

314159265358979

Mit Deadlocks hatte ich jedenfalls noch nie zu kämpfen

In meinem Fall musste nach dem Aufrufen der Funktionen für die Elemente auch noch eine gewisse Zeit gewartet werden, vielleicht ein paar Sekunden.

Ethon

314159265358979 schrieb:

Mit Deadlocks hatte ich jedenfalls noch nie zu kämpfen

In meinem Fall musste nach dem Aufrufen der Funktionen für die Elemente auch noch eine gewisse Zeit gewartet werden, vielleicht ein paar Sekunden.

Deadlocks entstehen ja auch nur, wenn du mehrere Dinge auf einmal locken musst.

314159265358979

Öh, ja. Falsches Wort, du hast Recht. Was ich meine, dürfte klar sein.