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.

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

Ich glaube nicht, dass die Spekulation über atomare Instruktionen in Bezug auf die gestellte Frage Sinn macht.

In DP geht es im Wesentlichen um Delphi, also um eine Hochsprache, die Umgebung sollte man generell als Black Box betrachten.

Somit kann man definieren:

Zitat:

Ein System (Programm) ist thread-sicher, wenn sein Zustand und damit die Zustände aller Subsysteme bei parallelen Aufrufen auf definierte Weise ändert.

Dies kann nur dann erreicht werden,

wenn das Programm nur Komponenten verwendet, die ihrerseits thread-sicher sind.
wenn der Zugriff und die Veränderung gemeinsam verwendeter Zustände aus geregelte Weise erfolgt.


P.S.
Übrigens gibt es eine Komponente System.SysUtils.TMultiReadExclusiveWriteSynchroniz er

@Mikkey&Olli73

Danke, genau das meinte ich.

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

Nutzt mir hier ein ThreadPool?

Benötige ich meinen Thread immer wieder, füttere ich „Ihn“ also nur mit neuen Daten und setze einen Event? Oder erzeuge ich den Thread jedes mal neu?

ich bin von den klassischen Anwendungen wie ThreadPools oder Ableitungen von der Klasse TThread ganz weg.
Bei mir gibt es eine Klasse "TThreadExecuter" .. die bekommt einfach einen MethodenPointer und ruft zyklisch wie ein Timer einen MethodenPointer der gewünschten Klasseauf. Meist 1 ms mit Sleep(1) .. aber oft ist das gar nicht notwendig.

So wird eine Funktion, die sich meistens ähnlich schimpft wie "CyclicMainJobs/ CyclicThreadProc" in einem anderen Thread aufgerufen.
Bei Bedarf kann der Aufruf auch schnell alternativ von einem "TTimerExecuter" durchgeführt werden, so wird anstatt eines zweiten Threads die Methode einfach von Hauptthread aus mit einem Timer aufgerufen.

Das Ganze hat den Vorteil, dass man auf alle Variablen der Klasse ohne Umstände Zugriffe hat.
Und das Ganze auch mehr zur "asynchronen" Eventverarbeitung tendiert und mit modernen OOP Konzepten gemeinsam harmoniert, als so eine popelige Schleife lediglich in der abgeleiteten Execute Procedure-

Mit einer übergebenen Instanz einer "SyncKlasse" können auch "teil-global" mehrere Objecte miteinander synchronisiert werden.

Das nur mal als "Brainstorming Idee"....

Aufpassen muss man natürlich, und genau drauf achten, welche Methoden von einem anderem als dem Hauptthread aufgerufen werden ..(werden können).. um dann sauber und ohne Fehler entsprechende Abschnitte im Code zu locken..

Zitat von stoxx:

Meist 1 ms mit Sleep(1) ..

An sich eine coole Idee, aber eine blöde Frage: Ist da nicht ein wenig zu viel context switching und overhead im spiel? Ok, 1000x pro Sekunde irgendwas aufrufen, um zu schauen, ob es etwas zu tun gibt, macht den Kohl nun auch nicht fett, aber ich dachte man ist vom Polling weggekommen. Oder habe ich das falsch verstanden?

Und welche Klasse meinst Du mit 'der gewünschten Klasse'? Und ist der 'Methodenpointer' in der 'gewünschten Klasse' nicht ein Verstoß gegen SRP? Schließlich macht die Methode etwas, das eher mit dem Thread bzw. einer Aktion im Thread zu zun hat, als mit der Klasse an sich.

Wie verhält es sich mit dem OCP, wenn Du eine weitere Aktion im Thread ausführen willst? Dann musst Du ja die gewünschte Klasse aufbohren, d.h. erweitern, obwohl Du an der Funktion der Klasse an sich nichts änderst?

Ich finde einen Workerthread(pool) mit Jobs, die man definiert, implementiert und den Arbeitern zur Verarbeitung gibt, immer noch am elegantesten. Man hat einen Pool pro Anwendung und schmeisst da die Jobs rein, fertig... ne, wie sagt der Fachmann und schon ist der Drops gelutscht.