#include <thread>
#include <mutex>
#include <list>

class service;

class user {
	std::recursive_mutex mutex_;
	std::shared_ptr<service> service_ptr_; 
public:
	user(std::shared_ptr<service> s) : mutex_(), service_ptr_(s) { }

	void operation() {
		std::unique_lock<std::recursive_mutex> lck(mutex_);
		// some operations
		service_ptr_->inform_all();
	}

	void inform() {
		std::unique_lock<std::recursive_mutex> lck(mutex_);
		// inform the client about something
	}
};

class service {
	std::recursive_mutex list_mutex_;
	std::list<std::shared_ptr<user>> users_;
public:
	service() : list_mutex_(), users_() { }

	void add_user() {
		std::unique_lock<std::recursive_mutex> lck(list_mutex_);
		users_.push_back(std::shared_ptr<user>(new user(this)));
	}

	void inform_all() {
		std::unique_lock<std::recursive_mutex> lck(list_mutex_);
		for(const auto& user : users_)
			user->inform();
	}

};

...

void some_multithreaded_fun(std::shared_ptr<service> service_ptr) {
	service_ptr->inform_all(); // zack
	...
}

void some_other_mt_fun(std::shared_ptr<user> user_ptr) {
	user_ptr->operation(); // zack
}

Die Funktionen some_multithreaded_fun und some_other_mt_fun laufen i.A. gleichzeitig in unterschiedlichen Threads. Wie man sehen kann, wird die erste Funktion erst den Mutex für die Liste und dann jedes User-Mutex einzeln locken, während die andere Funktion genau das umgekehrte tut, also passieren Deadlocks.
Was kann ich tun? Ich habe schon versucht, etwas mit std::lock zu spielen, aber damit habe ich mir immer nur die Kapselung der Klassen zerstört und ende darin, dass alle friends sind, was ich nicht will.

void operation() {
        {
            std::unique_lock<std::recursive_mutex> lck(mutex_);
            // some operations
        }
        service_ptr_->inform_all();
    }

Abgesehen von deinem Problem hast du hier in deinem Code noch ein paar kleinere Unschoenheiten.
- Der User braucht keinen shared_ptr auf den Service, da der Service offenbar immer laenger lebt als der User. Nimm stattdessen eine Referenz.
- Wenn der Service den User besitzt, kannst du hierfuer evtl unique_ptr einsetzen.
- Nimm in push_back make_shared anstatt explizit mit einem genewten User zu konstruieren. Das erlaubt es, den Refcount im selbst Speicherblock wie den User zu allozieren.
- Gibt es einen Grund, warum du eine std::list verwendest? (Hast du evtl. schon mal ueber concurrent-access Container nachgedacht, die mittels atomics implementiert sind?)
- some_multithreaded_fun und some_other_mt_fun sollten den shared_ptr per const-ref nehmen, um sinnloses inkrementieren und dekrementieren des Refcounts zu vermeiden. Das gilt generell fuer shared_ptr als Parameter, auch fuer den Konstruktor des Users z.B.
- Du musst die mutex Konstruktoren nicht explizit aufrufen. Das passiert von selbst bei Typen mit Default-Konstruktor.

> Wie waere es, wenn du operation() so umschreibst, dass sie den Mutex nur so lange wie noetig haelt?

Sieht irgendwie fehleranfällig aus. Wenn nun zwischen den Operationen und dem inform_all() ein anderer Thread am Zustand des Users etwas ändert, dann werden alle anderen Clients ja mit dem veralteten Zustand informiert. Der Zustand des Users sollte besser so lange vor anderen Threads geschützt sein, bis er an alle anderen User verteilt wurde, denke ich, sonst könnten andere User wiederrum auf die falsche Information falsch reagieren etc.

Ich habe hier einen sehr interessanten Artikel über hierachische Locks gefunden. Der sagt aus, dass man, wenn man z.B. ein Mutex auf Leven N gelockt hat, nur noch Mutexe locken kann, die unterhalb dieses Levels liegen. Diese Hierachie soll aus dem Software-Design hervorkommen, mein Design ruiniert das allerdings, wie man schön an some_other_mt_fun sehen kann:
Erst wird der User-Mutex gelockt, dann der User-Listen-Mutex und dann wieder der User-Mutex. Ich muss also irgendwas an dem Design ändern.

> - Der User braucht keinen shared_ptr auf den Service, da der Service offenbar immer laenger lebt als der User. Nimm stattdessen eine Referenz.

War ja nur exemplarisch.

> - Wenn der Service den User besitzt, kannst du hierfuer evtl unique_ptr einsetzen.

Andere Strukturen halten den User evtl. auch, also ist shared_ptr die bessere Wahl, besonders, falls sich das noch ändern sollte.

> - Nimm in push_back make_shared anstatt explizit mit einem genewten User zu konstruieren. Das erlaubt es, den Refcount im selbst Speicherblock wie den User zu allozieren.

Okay.

> - Gibt es einen Grund, warum du eine std::list verwendest? (Hast du evtl. schon mal ueber concurrent-access Container nachgedacht, die mittels atomics implementiert sind?)

Hat die Stdlib denn sowas?

> - some_multithreaded_fun und some_other_mt_fun sollten den shared_ptr per const-ref nehmen, um sinnloses inkrementieren und dekrementieren des Refcounts zu vermeiden. Das gilt generell fuer shared_ptr als Parameter, auch fuer den Konstruktor des Users z.B.

Stimmt.

> - Du musst die mutex Konstruktoren nicht explizit aufrufen. Das passiert von selbst bei Typen mit Default-Konstruktor.

Aber nach Standard muss doch die Liste in der Deklarationsreihenfolge sein. Kann ich Member mit Default-Konstruktor da einfach überspringen?

Der Zustand des Users sollte besser so lange vor anderen Threads geschützt sein, bis er an alle anderen User verteilt wurde, denke ich, sonst könnten andere User wiederrum auf die falsche Information falsch reagieren etc.

Ich sehe nicht so wirklich, weshalb das nötig sein sollte. Zur Not machst du halt eine Kopie mit dem neuen Status und verteilst diese.

Aber angenommen, du bist wirklich sicher, dass das der einzige gangbare Weg ist, dann ist der recursive_mutex im service immer noch unnötig.

class service {
    std::mutex mutex;
    std::deque<user> users;
    std::deque<user>::iterator begin;
    std::atomic<std::deque<user>::iterator> end;
public:
    service() : begin(users.begin()), end(users.end()) { }

    void add_user() {
        std::unique_lock<std::mutex> guard(mutex); // könnte man mit geeigneter Datenstruktur auch lock-free machen
        users.emplace_back(this);
        end.store(users.end());
    }

    void inform_all() {
        std::deque<user>::iterator end = this->end.load();
        for (auto it=begin; it!=end; ++it)
           it->inform();
    }

};

Desweiteren würde ich user vollständig von service entkoppeln und eine std::function<void()> bzw. Templates verwenden um inform auszuführen.

Ansonsten ein Quick-Fix von deinem broken Design:

class user {
    std::mutex operation_mutex_;
    std::mutex access_mutex_;
    std::shared_ptr<service> service_ptr_;
public:
    user(std::shared_ptr<service> s) : service_ptr_(s) { }

    void operation() {
        // Angepasste Lösung von Kellerautomat:
        // Nur ein Thread darf operieren
        std::unique_lock<std::mutex> lck(operation_mutex_);
        {
          std::unique_lock<std::mutex> lck(access_mutex_);
          // some operations
        }
        // access wird freigegeben, jetzt kann die Liste informieren
        service_ptr_->inform_all();
    }

    void inform() {
        std::unique_lock<std::mutex> lck(access_mutex_);
        // inform the client about something
    }
};

operation: user-op { 1. user-acc, 2. liste }
inform_all: liste { user-acc }

Die Übliche Variante wäre aber zu definieren:
Mutexen werden in Reihenfolge der Funktionsaufrufe gelockt. Also High-Level vor Low-Level.
Das setzt natürlich voraus dass man eine halbwegs saubere Dependency-Struktur hat, was aber meist nicht das grosse Problem ist.
Weiters darf man *keine* Mutexen gelockt halten während man Callbacks macht -- also beliebigen Code aufruft den man von anderen Programmteilen untergejubelt bekommt.

Nach dieser Auffassung hast du hier zwei Problemfunktionen:
* service::inform_all hält ne Mutex während eines Callbacks
* user::operation hält ne Mutex während es eine Funktion aufruft die wiederrum Callbacks aufruft

Der "Fix" für service::inform_all ist...
* Lock Mutex
* Kopiere Userliste
* Unlock Mutex
* Gehe Kopie der Userliste durch und rufe Callbacks auf

Dummerweise kann es dabei aber zu Problemen kommen wenn z.B. ein User gelöscht wird -- er könnte noch in einer lokalen Kopie der Userliste enthalten sein, und dann würden wir eine Funktion auf ein gelöschtes Objekt aufrufen.
Also brauchen wir shared_ptr.
Die Kopie der Userliste verwendet dann z.B. weak_ptr, und während der eigentliche Callback läuft hält ein temoprärer shared_ptr das Objekt am Leben.

Dass ein User schon gar nicht mehr in der User Liste enthalten ist während er einen Callback bekommt kann trotzdem sein, aber zumindest können wir dadurch garantieren dass das User Objekt noch existiert.

Und die Lösung für user::operation ist trivial: einfach den Lock freigeben bevor die inform_all Funktion aufgerufen wird.

Jodocus schrieb:

Ich habe hier einen sehr interessanten Artikel über hierachische Locks gefunden. Der sagt aus, dass man, wenn man z.B. ein Mutex auf Leven N gelockt hat, nur noch Mutexe locken kann, die unterhalb dieses Levels liegen. Diese Hierachie soll aus dem Software-Design hervorkommen,

Das ist im Prinzip das was ich geschrieben habe, nur besser erklärt

mein Design ruiniert das allerdings, wie man schön an some_other_mt_fun sehen kann:
Erst wird der User-Mutex gelockt, dann der User-Listen-Mutex und dann wieder der User-Mutex. Ich muss also irgendwas an dem Design ändern.

Japp.
Wobei es hier zwei Möglichkeiten gibt:

1. Du definierst dass service "über" user steht. Dann ist die Implementierung deiner inform_all Methode noch OK, das Problem ist dann alleine der Aufruf von inform_all aus der user Klasse, während du die user Mutex gelockt hast.

2. Du siehst das it->inform() als Callback an, d.h. sagst "da darf beliebiger Code drinnen stehen". Das ist die Variante die ich oben angenommen habe. In dem Fall musst du schon während des it->inform() Aufrufs sicherstellen dass keine Mutexen gelockt sind.

> - Gibt es einen Grund, warum du eine std::list verwendest? (Hast du evtl. schon mal ueber concurrent-access Container nachgedacht, die mittels atomics implementiert sind?)

Hat die Stdlib denn sowas?

Leider (noch) nicht. Aber solange kannst du dir mit TBB behelfen. Es gibt da unter anderem concurrent_vector, concurrent_unordered_set, concurrent_unordered_map und concurrent_hash_map. Je nachdem, was fuer deinen Fall am ehesten passt.

Jodocus schrieb:

> - Du musst die mutex Konstruktoren nicht explizit aufrufen. Das passiert von selbst bei Typen mit Default-Konstruktor.

Aber nach Standard muss doch die Liste in der Deklarationsreihenfolge sein. Kann ich Member mit Default-Konstruktor da einfach überspringen?

Ja.