Warum laufen diese Threads nicht in der richtigen Reihenfolge?

Was Ihr Mutex erreicht, ist, dass keine zwei Threads gleichzeitig gedruckt werden. Allerdings rasen sie immer noch, für welchen Thread er zuerst den Mutex erwirbt.

Wenn Sie eine serielle Ausführung haben wollen, können Sie nur Threads vermeiden.

Es hängt völlig vom Betriebssystem ab, in welcher Reihenfolge Threads geplant sind. Sie können sich nicht auf eine Bestellung verlassen. Angenommen, es ist völlig zufällig.

Sie übergeben Lambda an emplace_back, das als Parameter für den Konstruktor std :: thread verwendet wird. Siehe die Details für emplace_back copy / pasted von cppreference.com.

"Fügt dem Ende des Containers ein neues Element hinzu. Das Element wird durch std :: allocator_traits :: construct erstellt, das normalerweise placement-new verwendet, um das Element an der vom Container bereitgestellten Position zu erstellen arguments args ... werden als std :: forward (args) .... "

Ссылка

Der Mutex im Body des Lambda hat keine Auswirkungen, bis das std :: thread-Objekt vollständig konstruiert wurde und den durch den Lambda-Körper definierten Thread-Eintrittspunkt ausführt. Einige der std :: -Threads können während der Schleife gestartet werden, oder die Threads werden möglicherweise erst nach Abschluss der Schleife gestartet. Sie können das nicht auf eine tragbare Weise herausfinden.

Nachdem die for-Schleife alle std :: -Threads in Ihrem Vektor erstellt hat, muss das Betriebssystem entscheiden, in welcher Reihenfolge die Threads ausgeführt werden sollen und auf diese Weise erhalten Sie die zufällige Reihenfolge Ihrer Ausgabe.

Die Ausführungsreihenfolge ist unerheblich, Sie können sie nicht vorhersagen und sie wird sich in einem gegebenen Lauf von Lauf zu Lauf und über die Zeit ändern.

Ihre Designs sollten niemals von der Ausführungsreihenfolge der Threads abhängig sein.

Es geht noch weiter: Wenn N-Threads auf ein Synchronisationsobjekt warten, sagen wir einen Mutex, und der Mutex freigegeben wird, gibt es keine Möglichkeit, zuverlässig und portabel vorherzusagen, welcher der wartenden Threads erwacht und den Mutex ergreift Als nächstes, unabhängig von ihren relativen Zeitplan Prioritäten.

Nicht-Determinismus macht Multithread-Programmierung schwierig: -)