Threads & Mutexe - Frage zu gleichzeitigem Zugriff
-
Wenn man in einem Programm zwei Threads startet, werden die ja nur scheinbar parallel abgearbeitet. Das Betriebssystem gibt jedem Thread immer wieder Rechenzeit, so wie es das ja auch bei Prozessen macht. Das heißt, dass zu einer Zeit nur ein Thread arbeitet.
Ich hab mich mal gefragt, wie das mit den Mutexen funktioniert. Die Idee, die ich dann hatte, sieht so aus:
Thread A lockt Mutex 1 und macht irgendwas mit Variable Var. Nun bekommt Thread B vom Betriebssystem Rechenzeit (und A wird "pausiert") und will auch Mutex 1 locken, da er ebenfalls Var bearbeiten will. Da Thread A den Mutex aber bereits gelockt hat, muss B warten. Das Betriebssystem gibt also wieder Thread A Rechenzeit. Das geht dann so lange, bis Thread A den Mutex freigibt. Jetzt kann auch B Var bearbeiten.
Ist das so weit richtig?
Wie funktioniert das dann bei hardwareseitigem Threading (z. B. bei Hyper-Threading)? Wie ich das verstanden hab, handelt es sich dabei ja um echte Parallelisierung. Das heißt, wenn auf einem Prozessor Thread A läuft und auf dem anderen Thread B, laufen die Gefahr, dass sie genau zur gleichen Zeit den Mutex locken und somit beide die Variable bearbeiten können. Das kann bei Obigem ja nicht passsieren, da tatsächlich immer nur ein Thread zu einer Zeit aktiv ist.
Klärt mich bitte auf
-
Auch in diesem Fall wird ein Thread zuerst da sein und den Mutex locken.
-
daddy_felix schrieb:
Auch in diesem Fall wird ein Thread zuerst da sein und den Mutex locken.
Ich stelle mal eine Hypothese auf: Du hast das Problem nicht verstanden.
-
Threader schrieb:
Wenn man in einem Programm zwei Threads startet, werden die ja nur scheinbar parallel abgearbeitet. Das Betriebssystem gibt jedem Thread immer wieder Rechenzeit, so wie es das ja auch bei Prozessen macht. Das heißt, dass zu einer Zeit nur ein Thread arbeitet.
Wie kommst du auf die Idee? Selbst ein Smartphone hat heute mindestens 2 Kerne, die die Threads natürlich parallel ausführen!
-
Threader schrieb:
Wenn man in einem Programm zwei Threads startet, werden die ja nur scheinbar parallel abgearbeitet. Das Betriebssystem gibt jedem Thread immer wieder Rechenzeit, so wie es das ja auch bei Prozessen macht. Das heißt, dass zu einer Zeit nur ein Thread arbeitet.
Solange du mit einer singlecore-cpu arbeitest, die auch kein hyperthreading hat, sollte das soweit richtig sein.
Threader schrieb:
Ich hab mich mal gefragt, wie das mit den Mutexen funktioniert. Die Idee, die ich dann hatte, sieht so aus:
[...]
Ist das so weit richtig?
Hört sich auch richtig an.
Threader schrieb:
Wie funktioniert das dann bei hardwareseitigem Threading (z. B. bei Hyper-Threading)? Wie ich das verstanden hab, handelt es sich dabei ja um echte Parallelisierung. Das heißt, wenn auf einem Prozessor Thread A läuft und auf dem anderen Thread B, laufen die Gefahr, dass sie genau zur gleichen Zeit den Mutex locken und somit beide die Variable bearbeiten können. Das kann bei Obigem ja nicht passsieren, da tatsächlich immer nur ein Thread zu einer Zeit aktiv ist.
Dafür werden soweit ich weiß minilocks verwendet, die von der cpu direkt unterstützt werden.
Schau mal hier:
http://de.wikipedia.org/wiki/Compare-and-swap
-
manni66 schrieb:
Wie kommst du auf die Idee? Selbst ein Smartphone hat heute mindestens 2 Kerne, die die Threads natürlich parallel ausführen!
Noch eine Hypothese: Du hast die Frage einfach mal ignoriert und irgendwelchen irrelevanten Quatsch geschrieben.
@TE:
Vielleicht interessiert dich das: www.jopdesign.com/doc/SynMCPs.pdf
-
Wie funktioniert das dann bei hardwareseitigem Threading
Na mt Hardware. Der Prozessor enthaelt bestimmte Komponenten, die sicherstellen, dass der Zugriff nicht parallel geschieht sondern sequenziell. Das kann Compare-und-Swap sein, muss aber nicht.
-
@Threader
Na bei "echtem" multithreading ist da grundsätzlich nichts anders als bei "nicht echtem", das OS bzw. die Library die die Mutex implementiert stellt sicher, dass nur ein Thread die gleichzeitig gelockt haben kann, der andere muss warten.
Das geht auch mit mehr als einem Core.
Wie ist doch dabei erstmal nebensächlich.
-
Ich hab mich jetzt grad gefragt, was für ein C++ Problem dadurch entstanden ist, aber es geht generell um die Frage. Ich glaube, den Vorteil, den Hyperthreading hat, ist, dass wenn zwei Threads ständig die gleichen Daten brauchen, sich die Daten im Cache befinden werden und ein mutex lock/unlock bewirkt, dass die Caches mit dem RAM abgeglichen werden und wenn es sich um Threads handelt, die auf dem gleichen Prozessor waren kann man sich den Schritt sparen. Ansonsten hat das nur Intel, andere können genauso auf Hyperthreading verzichten.
