Ich bin interessiert an der Performance von Mutex und Message Passing im neuesten gcc mit Threads basierend auf Pthreads und einer Ubuntu Entwicklungsumgebung. Ein gutes generisches Problem dafür sind die Speisephilosophen, wo jeder Philosoph die links und rechts benachbarten Nachbarn benutzt. Ich erhöhe die Zahl der Philosophen auf 99, um meinen Vierkernprozessor beschäftigt zu halten.
%Vor%Der obige Code erlaubt meinem Philosophen zu versuchen, die zwei Gabeln zu ergreifen, mit denen sie essen müssen.
%Vor%Der obige Code überwacht meine Philosophen Fortschritte zu essen oder zu denken, abhängig davon, ob sie es schaffen, die zwei Gabeln zu reservieren.
%Vor%Der obige Code wartet darauf, dass alle Philosophen die Auswahl vervollständigen, nach dieser Zeit kann der Philosoph einen neuen Versuch machen:
%Vor%Ich habe einen Hauptfaden, der die Philosophen überwacht und sie von einem Zyklus zum nächsten bewegt, der ihnen ungefähr 10 Sekunden erlaubt, zu essen und zu denken, soviel sie können. Das Ergebnis ist etwa 9540 Zyklen mit einigen hungernden Philosophen und anderen, die viel zu essen haben und viel Zeit zum Nachdenken haben! Also muss ich meine Philosophen vor dem Verhungern schützen und zu lange warten, damit ich mehr Logik hinzufüge, um ein Überessen zu verhindern, indem ich die essenden Philosophen dazu auffordere, nach einer sehr kleinen Pause die gleichen Gabeln loszulassen und nachzudenken:
%Vor%Jetzt habe ich 9598 Zyklen, wobei jeder Philosoph einen relativ gleichen Anteil an Essen bekommt (2620 - 2681) und mit der längsten Wartezeit von 14 denkt. Nicht schlecht. Aber ich bin nicht zufrieden damit, jetzt werde ich alle Mutex und Locks los und behalte es einfach mit den geraden Philosophen, die in geraden Zyklen und den ungeraden Philosophen essen, die in den ungeraden Zyklen essen. Ich benutze eine einfache Methode der Synchronisierung der Philosophen
%Vor%Verhindert, dass ein Philosoph mit einem globalen Zykluszähler zu oft isst oder denkt. Zur gleichen Zeit und die Philosophen verwalten etwa 73543 Zyklen mit 36400 Essen und nicht mehr als 3 Zyklen warten. Mein einfacher Algorithmus ohne Sperren ist also schneller und hat eine bessere Verteilung der Verarbeitung zwischen den verschiedenen Threads.
Kann jemand an einen besseren Weg denken, dieses Problem zu lösen? Ich befürchte, dass ich, wenn ich ein komplexes System mit mehreren Threads implementiere, wenn ich den traditionellen Mutex- und Message-Passing-Techniken folge, mit einer langsameren als notwendigen und möglicherweise unsymmetrischen Verarbeitung der verschiedenen Threads in meinem System fertig werde.
Dies ist eine interessante Möglichkeit, die Probleme des Threads in C ++ zu untersuchen.
Um bestimmte Punkte anzusprechen:
Ich fürchte, wenn ich ein komplexes System mit mehreren Threads implementiere, dass ich, wenn ich traditionellen Mutex- und Message-Passing-Techniken folge, mit langsameren als notwendigen und möglichen unausgewogenen Verarbeitungen auf den verschiedenen Threads in meinem System fertig werde.
Leider ist die beste Antwort, die ich Ihnen geben kann, dass dies eine begründete Angst ist. Die Kosten für Planung und Synchronisation sind jedoch sehr spezifisch für die Anwendung - dies wird zu einer technischen Entscheidung beim Entwurf eines großen Systems. In erster Linie ist die Planung NP-Hard ( Ссылка ), aber hat gute Annäherungen.
Was Ihr konkretes Beispiel betrifft, so ist es meiner Meinung nach schwierig, aus den Ergebnissen, die Sie präsentieren, allgemeine Schlüsse zu ziehen - es gibt einen primären Ausgangspunkt: den Kompromiss zwischen grober Kornsynchronisation und feinkörniger Synchronisation. Dies ist ein gut untersuchtes Problem und einige Forschungsergebnisse können hilfreich sein (zB Ссылка ).
Insgesamt handelt es sich um ein technisches Problem, das spezifisch für das zu lösende Problem, das Betriebssystem und die Hardware ist.
Tags und Links c++ c++11 concurrency