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