Zitat von stoxx:

Mir ist nichts von einer Lockingmöglichkeit jeder einzelnen Zelle im Arbeitsspeicher bekannt.

Soweit ich weiß, sollte bis in die Caches hinein der Lock-Präfix funktionieren. Danach muss man sich eh mit Cache-Kohärenz herumschlagen.

Eigentlich bezweifle ich, dass man für die meisten Anwendungen wirklich in die Untiefen in der parallele Programmierung eintauchen muss. CriticalSections, Semaphoren, ReaderWriter und das Synchronize sollten für vieles ausreichen.

Zitat von Sir Rufo:

Kann eigentlich nicht möglich sein, denn dann müssten sich beide zur exakt selben Zeit auf dem Bus zum Speicher befinden ... wie soll das sinnvoll gehen?

Beide schreiben in ihren eigenen Cache (EDIT: beziehungsweise andere Puffer and Warteschlangen im Prozessor) und sehen zu dieser Zeit nicht die Änderungen, die der andere gemacht hat. Beide sehen nur ihre eigenen Änderungen, solange es nicht zwischendurch etwas wie mfence-Operationen gibt. Irgendwer "gewinnt" dann und bestimmt den physischen Stand im Hauptspeicher, aber dann ist der Schaden schon angerichtet.

Zitat von Sir Rufo:

Bei den aktuellen XEON-MultiCore-Boards hat übrigens jede CPU ihren eigenen Speicher.

Ich nehme mal an, das geht in Richtung NUMA-Architektur. Vielleicht hast du einen Link, wo das genauer beschrieben ist?


Viel cooler ist der transaktionale Speicher, den Intel in der Haswell-Generation eingeführt hat. Aber bis man darauf in Delphi zurückgreifen kann, vergehen vermutlich noch ein paar Dekaden.

Zitat von BUG:

Zitat von Sir Rufo:

Bei den aktuellen XEON-MultiCore-Boards hat übrigens jede CPU ihren eigenen Speicher.

Ich nehme mal an, das geht in Richtung NUMA-Architektur. Vielleicht hast du einen Link, wo das genauer beschrieben ist?

Hier auf Seite 22 (bzw. Seite 10)
ISB.png

intel 3.2.2.2 Memory Slot Identification and Population Rules (S.25)

• The memory slots associated with a given processor are unavailable if the corresponding processor socket is not populated.
• A processor may be installed without populating the associated memory slots provided a second processor is installed with associated memory. In this case, the memory is shared by the processors. However, the platform suffers performance degradation and latency due to the remote memory.

Gibt es eigentlich Prozesse, die Zugriffe nur bei schreibenden Zugriffen sperren?

CriticalSection.Enter verhindert ja (m.W.n) gleichzeitige lesende Zugriffe (z.B. 10 Zugriffe auf eine Liste). Stimmt das?

Dann wäre doch sinnvoll, z.B. 8 lesende Zugriffe mit
"CriticalSection.EnterRead" gleichzeitig zuzulassen und nur wenn dann ein "CriticalSection.EnterWrite" dazwischen kommen sollte die 8 Leseaktionen zu beenden, den Zugriff wirklich zu sperren und erst danach wieder andere Zugriffe zuzulassen.

Ist meine Überlegung sinnvoll? Oder gar schon so realisiert (in der Hilfe habe ich dazu nichts Genaues gefunden).

Critical Sections sorgen einfach dafür, das immer nur ein Thread beim Aufruf von 'Enter' sofort weiter macht. Bei allen anderen 'hängt' der Aufruf, bis der erste Thread (oder wer auch immer) das 'Leave' der CS Aufruf.

Zitat von Dejan Vu:

Critical Sections sorgen einfach dafür, das immer nur ein Thread beim Aufruf von 'Enter' sofort weiter macht. Bei allen anderen 'hängt' der Aufruf, bis der erste Thread (oder wer auch immer) das 'Leave' der CS Aufruf.

Genau hier würde ich es eben für sinnvoll halten, wenn der Zugriff erst gesperrt würde, wenn ein schreibender Zugriff ins Spiel kommt.
Wollen 10 oder 100 Threads gleichzeitig NUR LESEN wäre das ja eigentlich völlig unkritisch.

U.U. könnte das eine Anwendung deutlich beschleunigen.

Zitat von stahli:

Dann wäre doch sinnvoll, z.B. 8 lesende Zugriffe mit
"CriticalSection.EnterRead" gleichzeitig zuzulassen und nur wenn dann ein "CriticalSection.EnterWrite" dazwischen kommen sollte die 8 Leseaktionen zu beenden, den Zugriff wirklich zu sperren und erst danach wieder andere Zugriffe zuzulassen.

Ist meine Überlegung sinnvoll? Oder gar schon so realisiert (in der Hilfe habe ich dazu nichts Genaues gefunden).

Multi-read-Exclusive-write-Synchronizer

Zitat von Sir Rufo:

Bei den aktuellen XEON-MultiCore-Boards hat übrigens jede CPU ihren eigenen Speicher.
[*]The memory slots associated with a given processor are unavailable if the corresponding processor socket is not populated.[*]A processor may be installed without populating the associated memory slots provided a second processor is installed with associated memory. In this case, the memory is shared by the processors. However, the platform suffers performance degradation and latency due to the remote memory.

Das ist aber nicht so richtig das was wir wollen. Scheinbar ist diese Architektur den immer weiter verbreiteten virtuellen (Cloud) Lösungen vorbehalten.
Es ging ja darum, gemeinsamenm Speicher gleichzeitig bearbeiten zu können.
Dass jeder Thread seinen eigenen Speicher bekommt, wäre mit jeder Architektur mit unterschiedlichen Variablen nicht sonderlich schwer zu lösen...

Zitat von stoxx:

Zitat von Sir Rufo:

Bei den aktuellen XEON-MultiCore-Boards hat übrigens jede CPU ihren eigenen Speicher.
[*]The memory slots associated with a given processor are unavailable if the corresponding processor socket is not populated.[*]A processor may be installed without populating the associated memory slots provided a second processor is installed with associated memory. In this case, the memory is shared by the processors. However, the platform suffers performance degradation and latency due to the remote memory.

Das ist aber nicht so richtig das was wir wollen. Scheinbar ist diese Architektur den immer weiter verbreiteten virtuellen (Cloud) Lösungen vorbehalten.
Es ging ja darum, gemeinsamenm Speicher gleichzeitig bearbeiten zu können.
Dass jeder Thread seinen eigenen Speicher bekommt, wäre mit jeder Architektur mit unterschiedlichen Variablen nicht sonderlich schwer zu lösen...

Die Situation bleibt aber doch gleich, oder weißt du auf welchem Core und welchem Riegel der Wert nun zu finden ist? Und wenn ich der Speicherstelle x einen Wert übergebe, dann muss jeder Thread von dieser Speicherstelle genau den geschriebenen Wert auslesen können.

Das war ja auch nur wegen MultiCore und alle teilen sich einen Arbeitsspeicher