Zitat von Sir Rufo:

@stoxx
Bei 32bit werden allerdings - soweit mir bekannt - immer genau 4 Bytes (=32bit) bearbeitet, und deswegen ist ein 8/16/24/32bit-Wert auf einem 32bit-Betriebssystem threadsafe, denn die CPU lockt dafür den Speicherplatz (32bit) im Arbeitsspeicher.

Also man stelle sich einfach mal 2 echte Prozessoren auf 2 Sockel auf einem Mainboard vor.
Mir ist nichts von einer Lockingmöglichkeit jeder einzelnen Zelle im Arbeitsspeicher bekannt.
Was meinst Du damit?

Ich kann Dir nur sagen, dass auf einem echten Dual XEON Server mit 2 echten CPU's alle Programmierfehler noch viel kritischer sind und zu lustigen Abstürzen führen können, was auf einem Single Socket Mainboard, selbst mit zig Cores noch problemos funktionieren kann.

Zitat von stoxx:

Zitat von Sir Rufo:

@stoxx
Bei 32bit werden allerdings - soweit mir bekannt - immer genau 4 Bytes (=32bit) bearbeitet, und deswegen ist ein 8/16/24/32bit-Wert auf einem 32bit-Betriebssystem threadsafe, denn die CPU lockt dafür den Speicherplatz (32bit) im Arbeitsspeicher.

Also man stelle sich einfach mal 2 echte Prozessoren auf 2 Sockel auf einem Mainboard vor.
Mir ist nichts von einer Lockingmöglichkeit jeder einzelnen Zelle im Arbeitsspeicher bekannt.
Was meinst Du damit?

Nun ich kann mir nicht vorstellen, 2-n echte Prozessoren es schaffen sollten ein und die selbe Speicheradresse im selben/gleichen Moment zu beschreiben. 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?

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

Zitat von stoxx:

Ich kann Dir nur sagen, dass auf einem echten Dual XEON Server mit 2 echten CPU's alle Programmierfehler noch viel kritischer sind und zu lustigen Abstürzen führen können, was auf einem Single Socket Mainboard, selbst mit zig Cores noch problemos funktionieren kann.

Ist halt eine andere Liga

Zitat von Sir Rufo:

Nun ich kann mir nicht vorstellen, 2-n echte Prozessoren es schaffen sollten ein und die selbe Speicheradresse im selben/gleichen Moment zu beschreiben. 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?

da bin ich technisch im Moment überfragt. Aber Du hast immer das Problem, dass 2 Threads eine Variable lesen können, eine gewisse Zeit damit was tun, und diese wieder zurückschreiben. Selbst wenn der Lese und Schreibvorgang nicht gleichzeitig erfolgt, kann die Verarbeitung fast parallel verlaufen und logisch falsch sein. (Eben z.b. irgendwas hochzählen)
Ich hab da morgen nochmal einen schönen Link dazu mit Delphi Beispielsourecode.
Wenn man mit 2 Threads ungesichert eine gemeinsame Variable hochzählen lässt, und jeder Thread für sich auch nochmal zusätzlich einen Counter hochzählt, dann stimmt die Summe nicht überein mit der gemeinsam hochgezählten Variablen.

Zitat von Sir Rufo:

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

naja .. eine Variable, ein Speicher .. RAM gibts nur einmal ..
Ich meine ja nicht den Cache sondern den echten physischen RAM. (Als Riegel )


http://de.wikipedia.org/wiki/DDR-SDRAM

Zitat von stoxx:

Zitat von Sir Rufo:

Nun ich kann mir nicht vorstellen, 2-n echte Prozessoren es schaffen sollten ein und die selbe Speicheradresse im selben/gleichen Moment zu beschreiben. 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?

da bin ich technisch im Moment überfragt. Aber Du hast immer das Problem, dass 2 Threads eine Variable lesen können, eine gewisse Zeit damit was tun, und diese wieder zurückschreiben. Selbst wenn der Lese und Schreibvorgang nicht gleichzeitig erfolgt, kann die Verarbeitung fast parallel verlaufen und logisch falsch sein. (Eben z.b. irgendwas hochzählen)
Ich hab da morgen nochmal einen schönen Link dazu mit Delphi Beispielsourecode.
Wenn man mit 2 Threads ungesichert eine gemeinsame Variable hochzählen lässt, und jeder Thread für sich auch nochmal zusätzlich einen Counter hochzählt, dann stimmt die Summe nicht überein mit der gemeinsam hochgezählten Variablen.

Da haben wir aber aneinander vorbeigeredet. Das ist ja auch logisch, denn ein Thread-Cycle ist nicht zwangsläufig gleich einem CPU-Cycle. Und wenn ich einen Wert aus dem Speicher lese, dann habe ich den Wert, den er zu diesem Zeitpunkt hatte, einen CPU-Zyklus später, kann das eben völlig anders sein. Dafür gibt es ja auch extra InterlockedIncrement.

Es ist aber völlig unproblematisch auf einem 32bit-Betriebssystem einen 32bit-Wert in ein und dieselbe Speicherstelle mit mehreren Threads zu schreiben und auch zu lesen ohne einen Zugriffsfehler zu bekommen. Denn der Zugriff darauf erfolgt in einem Rutsch.

Zitat von stoxx:

Zitat von Sir Rufo:

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

naja .. eine Variable, ein Speicher .. RAM gibts nur einmal ..
Ich meine ja nicht den Cache sondern den echten physischen RAM. (Als Riegel )
http://de.wikipedia.org/wiki/DDR-SDRAM

Ich meine auch die Riegel und da hat jeder CPU-Klotz seine eigenen Riegel

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)

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.

Ich habe das Thema nur oberflächlich überflogen. Was ich kurz anmerken wollte:

Zitat von Sir Rufo:

Bei 32bit werden allerdings - soweit mir bekannt - immer genau 4 Bytes (=32bit) bearbeitet, und deswegen ist ein 8/16/24/32bit-Wert auf einem 32bit-Betriebssystem threadsafe, denn die CPU lockt dafür den Speicherplatz (32bit) im Arbeitsspeicher

Wenn ich das nicht falsch verstanden habe, muss man aber auch bei Pascal in einem Sonderfall aufpassen: Wenn der Integer in einem packet record steckt- Dann ist der doch nicht unbedingt so ausgerichtet dass die CPU den in einem Rutsch ins Register schaufelt und zwei Takte braucht.

Irgendwie sowas, oder?

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.