Tatsächlich ist es genau das Gleiche wie jedes Parallelitätsproblem: Sie haben mehrere Threads der Kontrolle, und es ist unbestimmt, welche Anweisungen wann welche Threads ausgeführt werden. Das heißt, es gibt eine große Anzahl von POTENTIAL-Ausführungspfaden durch das Programm, und Ihr Programm muss unter allen korrekt sein.
Im Allgemeinen ist der Ort, an dem Probleme auftreten können, wenn der Status unter den Threads geteilt wird (auch bekannt als "leichte Prozesse" in den alten Tagen). Das passiert, wenn es geteilte Speicherbereiche gibt,
Um die Korrektheit sicherzustellen, müssen Sie sicherstellen, dass diese Datenbereiche so aktualisiert werden, dass keine Fehler auftreten. Dazu müssen Sie "kritische Bereiche" des Programms identifizieren, in denen der sequentielle Betrieb gewährleistet sein muss. Diese können so wenig wie eine einzige Anweisung oder Codezeile sein; Wenn die Sprache und die Architektur sicherstellen, dass diese atomar sind, dh nicht unterbrochen werden können, dann bist du golden.
Sonst wirst du diesen Abschnitt unkenntlich machen und eine Art Wächter darauf setzen. Der klassische Weg besteht darin, einen -Semaphor zu verwenden, bei dem es sich um eine atomare Anweisung handelt, die nur einen Thread der Kontrolle gleichzeitig überlässt. Diese wurden von Edsgar Dijkstra erfunden, und so haben Namen, die aus den Niederlanden kommen, P und V . Wenn Sie zu einem P kommen, kann nur ein Thread fortfahren; Alle anderen Threads werden in die Warteschlange gestellt und warten, bis der ausführende Thread zur zugehörigen Operation V gelangt.
Da diese Primitiven etwas primitiv sind und weil die holländischen Namen nicht sehr intuitiv sind, wurden einige größere Ansätze entwickelt.
Per Brinch-Hansen hat den Monitor erfunden, der im Grunde nur eine Datenstruktur mit atomar garantierten Operationen ist; Sie können mit Semaphoren implementiert werden. Monitore sind ziemlich genau das, worauf Java synchronized -Anweisungen basieren; Sie bewirken, dass ein Objekt oder ein Codeblock dieses bestimmte Verhalten hat - das heißt, nur ein Thread kann gleichzeitig "in" sein - mit einfacherer Syntax.
Es sind andere Modale möglich. Haskell und Erlang lösen das Problem, indem sie funktionale Sprachen sind, die es niemals zulassen, dass eine Variable nach der Erstellung geändert wird. das bedeutet, dass sie sich natürlich nicht um Synchronisation kümmern müssen. Einige neue Sprachen, wie Clojure, haben stattdessen eine Struktur namens "transactional memory", was bedeutet, dass, wenn eine Zuweisung ist, die Zuordnung atomar und reversibel ist.
Also das ist es in aller Kürze. Um wirklich etwas darüber zu erfahren, sind die besten Orte, um sich mit Betriebssystemtexten zu befassen, wie zB Andy Tannenbaums Text .
Die zwei am häufigsten verwendeten Mechanismen für die Thread-Kommunikation sind der gemeinsame Status und Nachrichtenweitergabe .
Die gängigste Methode für die Kommunikation von Threads ist eine gemeinsame Datenstruktur, in der Regel eine Warteschlange. Einige Threads stellen Informationen in die Warteschlange, während andere sie herausnehmen. Die Warteschlange muss durch Betriebssystemeinrichtungen wie Mutexe und Semaphoren geschützt werden. Interrupts haben damit nichts zu tun.
Wenn Sie wirklich an einer Theorie der Thread-Kommunikation interessiert sind, sollten Sie sich Formalismen wie die Kalkül .
Um zwischen Threads zu kommunizieren, müssen Sie den von Ihrem Betriebssystem und / oder Ihrer Laufzeit bereitgestellten Mechanismus verwenden. Interrupts sind ungewöhnlich niedrig, obwohl sie implizit verwendet werden können, wenn Ihre Threads über Sockets oder Named Pipes kommunizieren.
Ein gebräuchliches Muster wäre die Implementierung eines gemeinsamen Zustands unter Verwendung eines gemeinsam genutzten Speicherblocks, der sich auf ein os-geliefertes Synchronisationsgrundelement wie einen Mutex verlässt, um Sie vor dem Warten zu schützen, wenn Sie aus dem Block lesen. Denken Sie daran, dass Sie, wenn Sie überhaupt Threads haben, bereits eine Art Scheduler haben müssen (egal, ob es vom Betriebssystem stammt oder in Ihrer Sprachlaufzeit emuliert wird). Dieser Scheduler kann daher Synchronisationsobjekte und eine "Schlaf" -Funktion bereitstellen, ohne notwendigerweise auf Hardware-Unterstützung angewiesen zu sein.
Sockets, Pipes und Shared Memory funktionieren auch zwischen Prozessen. Manchmal bietet eine Laufzeitumgebung eine leichtere Möglichkeit, die Synchronisierung für Threads innerhalb desselben Prozesses durchzuführen. Gemeinsamer Speicher ist in einem einzigen Prozess günstiger. Und manchmal gibt Ihnen Ihre Laufzeit auch einen atomaren Nachrichtenübermittlungsmechanismus.
Tags und Links c c++ multithreading theory