Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“

[stoxx]

Zitat:

Zitat von Sir Rufo (Beitrag 1264172)

@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.

[Sir Rufo]

Zitat:

Zitat von stoxx (Beitrag 1264176)

Zitat:

Zitat von Sir Rufo (Beitrag 1264172)

@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:

Zitat von stoxx (Beitrag 1264176)

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 :)

[stoxx]

Zitat:

Zitat von Sir Rufo (Beitrag 1264179)

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:

Zitat von Sir Rufo (Beitrag 1264179)

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

[Sir Rufo]

Zitat:

Zitat von stoxx (Beitrag 1264182)

Zitat:

Zitat von Sir Rufo (Beitrag 1264179)

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:

Zitat von stoxx (Beitrag 1264182)

Zitat:

Zitat von Sir Rufo (Beitrag 1264179)

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

[BUG]

Zitat:

Zitat von stoxx (Beitrag 1264176)

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:

Zitat von Sir Rufo (Beitrag 1264179)

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:

Zitat von Sir Rufo (Beitrag 1264179)

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.

[Sir Rufo]

Zitat:

Zitat von BUG (Beitrag 1264187)

Zitat:

Zitat von Sir Rufo (Beitrag 1264179)

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)
Anhang 41397

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.

[stahli]

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).

[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.

[Der schöne Günther]

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

Zitat:

Zitat von Sir Rufo (Beitrag 1264172)

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

Delphi-Quellcode:

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?

[stahli]

Zitat:

Zitat von Dejan Vu (Beitrag 1264261)

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.