ich lese gerade "C++ Concurrency in Action: Practical Multithreading" von Anthony Williams und verstehe den Sinn des custom destructors seiner threadsafe_list aus Listing 6.13 nicht.

Für die, die das Buch nicht haben: Die Liste, die er da beispielhaft vorstellt ist für die Nutzung in einer thread safe lookup table mit möglichst viel concurrency durch fine grained locks gedacht.

Mir leuchtet nicht ein, wieso der dtor nicht einfach der vom compiler generierte -ßdefault sein kann. Die Liste würde durch die unique_ptr dann doch ganz normal von hinten nach vorne aufgeräumt und alles wäre gut, oder?
Klar, falls noch ein anderer Thread irgendwas auf der Liste macht wär das doof, aber generell sind die die concurrent container im Buch eigentlich so designed, dass vor Begin der Zerstörung jegliche Nutzung abgeschlossen zu sein hat, weshalb hier eigentlich auch kein UB durch das zerstören einer noch gelockten Mutex drohen sollte.
Ist das also nur ein zusätzliches Sicherheitsding, oder übersehe ich irgendwas fundamentales?

template<typename T>
class threadsafe_list
{
	struct node
	{
		std::mutex m;
		std::shared_ptr<T> data;
		std::unique_ptr<node> next;
		node():
			next()
		{}

		node(T const& value):
			data(std::make_shared<T>(value))
		{}
	};

	node head;

public:
	threadsafe_list()
	{}

	~threadsafe_list()
	{
		remove_if([](node const&){return true;});
	}

	threadsafe_list(threadsafe_list const& other)=delete;
	threadsafe_list& operator=(threadsafe_list const& other)=delete;

	void push_front(T const& value)
	{
		std::unique_ptr<node> new_node(new node(value));
		std::lock_guard<std::mutex> lk(head.m);
		new_node->next=std::move(head.next);
		head.next=std::move(new_node);
	}

	template<typename Function>
	void for_each(Function f)
	{
		node* current=&head;
		std::unique_lock<std::mutex> lk(head.m);
		while(node* const next=current->next.get())
		{
			std::unique_lock<std::mutex> next_lk(next->m);
			lk.unlock();
			f(*next->data);
			current=next;
			lk=std::move(next_lk);
		}
	}

	template<typename Predicate>
	std::shared_ptr<T> find_first_if(Predicate p)
	{
		node* current=&head;
		std::unique_lock<std::mutex> lk(head.m);
		while(node* const next=current->next.get())
		{
			std::unique_lock<std::mutex> next_lk(next->m);
			lk.unlock();
			if(p(*next->data))
			{
				return next->data;
			}
			current=next;
			lk=std::move(next_lk);
		}
		return std::shared_ptr<T>();
	}

	template<typename Predicate>
	void remove_if(Predicate p)
	{
		node* current=&head;
		std::unique_lock<std::mutex> lk(head.m);
		while(node* const next=current->next.get())
		{
			std::unique_lock<std::mutex> next_lk(next->m);
			if(p(*next->data))
			{
				std::unique_ptr<node> old_next=std::move(current->next);
				current->next=std::move(next->next);
				next_lk.unlock();
			}
			else
			{
				lk.unlock();
				current=next;
				lk=std::move(next_lk);
			}
		}
	}
};

Würde im Defaultdestruktur ein Nodenmutex gesperrt?

Nein, aber müsste es?

Praedikat schrieb:

Die Lambda, die im Destruktor dem remove_if übgeben wird, gibt doch immer true zurück. die Liste wird also einfach so abgeräumt. Eine andere remove mthode brint die Klasse ja nicht mit.

Ja, schon klar, aber wieso lässt man sie nicht auf "natürlichem Weg" aufräumen?

übersehe ich irgendwas fundamentales?

Die Zerstörung eines mutex ist selbst nicht threadsafe. Mithin muss der zerstörende Thread für vorherige Synchronisation sorgen, andernfalls entstünde eine Race Condition (jedenfalls potentiell, das hängt davon ab, wie genau sicher gestellt wurde, dass alle operationen auf der Liste beendet sind), falls zuletzt ein anderer Thread den Mutex besessen hat.
Ein anderer Grund ist möglicherweise der, dass der Defaultkonstruktor die Liste rekursiv löscht, was potentiell zu einem Stacküberlauf führen könnte.

manni66 schrieb:

Würde im Defaultdestruktur ein Nodenmutex gesperrt?

Nein, aber müsste es?

1. ein Mutex garantiert, dass alle Prozessoren den gleichen Speicherinhalt sehen. Vor C++ 11 war das auf jeden Fall notwendig, soweit ich weiss ändert das neue Speichermodell daran nichts, wenn man keine Atomic Variablen benutzt.

2. warum sollte man darauf hoffen, dass schon alles gut geht, wenn man es absichern kann?

1. Nach dem Zerstören sollte sich eigentlich kein Prozessor den Speicherinhalt noch angucken.
2. Es wäre ja kein blindes Hoffen, weil man ja genau wüsste, in welcher Reihenfolge die Liste im default dtor zerstört würde, was ja auch unter der oben genannten Voraussetzung kein Problem wäre.

@camper: Na gut, ich hatte ihn so verstanden, dass für alle dtors in seinen Containern da die Grundvoraussetzung gilt, dass nach dem Start der Zerstörung kein anderer Thread mehr drauf zugreift. Wär also dann halt nur ein zusätzliches Sicherheitsding. Wundert mich halt, weil er das bei seinen anderen Containern (zb beim Stack) halt nicht macht. Der würde einem auch um die Ohren fliegen wenn man ihn zerstört während jemand anders noch drauf hantiert.
Stacküberlauf ist auch ne interessante Idee.

@manni66:

1. Nach dem Zerstören sollte sich eigentlich kein Prozessor den Speicherinhalt noch angucken.

Der zerstörende Prozess sollte aber das zuletzt geschriebene sehen.

Der zerstörende Thread sollte aber das zuletzt geschriebene sehen.

Alles, was geschrieben wurde, war dabei doch eh schon in Mutexe verpackt. Die dann beim Zerstören noch ein zweites mal alle durchzulocken, ist also unnötig.

manni66 schrieb:

Der zerstörende Thread sollte aber das zuletzt geschriebene sehen.

Alles, was geschrieben wurde, war dabei doch eh schon in Mutexe verpackt. Die dann beim Zerstören noch ein zweites mal alle durchzulocken, ist also unnötig.

Nein, so funktioniert das nicht. Nachdem ein Mutex gesperrt wurde, ist garantiert, dass der sperrende Thread alles "sieht", was vorher geschreiben wurde. Mehr nicht!

Warum er das dann beispielsweise bei seiner threadsafe_queue nicht macht, weiß ich zwar nicht, aber das ist ja ein anderes Thema.