Mutex nutzlos?

[ts-soft]

Du könntest die Variante von STARGÅTE nutzen, wenn Du die Zugriffe mit Try/Catch absicherst:
http://www.purebasic.fr/english/viewtop ... 39#p380239

Das sollte dann meiner Meinung nach sicher sein, aber sicher bin ich mir nicht

[STARGÅTE]

Betrifft also ein geteilter Speichernur den Zugriff? Eigentlich greifen selbst 100 Threads nie gleichzeitig auf ein Speicher zu, da jeder Schritt für Schritt abgearbeitet wird, oder nicht?

Richtig.
Aber wenn der Lese-Thread gerade das zu lesende Bild rendert (was ja Schritt für Schritt passiert), und du gerade bei Schreibe-Thread ein neues Bild an der Stelle einfügst, ließt der Lese-Thread in einem nicht mehr gültigem Speicher -> IMA

Was ohne Mutex geht ist zB in eine Long zu lesen und "gleichzeitig" zu schreiben, weil das jeweils nur ein "Schritt" ist.

[ts-soft]

Integerspeicherzugriffe sind die einzigen, die mit einer Operation auskommen, alle anderen benötigen mehrere Operationen,
was bei Zugriff mehrerer Threads unweigerlich zu undefiniertem Zustand führt.

[Lambda]

Das Bild ändert sich nicht. Lediglich Werte wie Winkel und Position müssen paralell und permanent sein.

Ich muss mich korrigieren, es läuft so zwar Problemlos, führt dennoch zu einem sichtbaren ruckeln. Der Thread ist wie gesagt mit TryLockMutex abgesichert(am Zeichnen-Abschnitt) , wenn aber die äußeren Befehle dem Thread das Mutex an der Abfrage meistens klauen führt das wieder zum ruckeln.

[NicTheQuick]

Integerspeicherzugriffe sind die einzigen, die mit einer Operation auskommen, alle anderen benötigen mehrere Operationen,
was bei Zugriff mehrerer Threads unweigerlich zu undefiniertem Zustand führt.

Das stimmt nicht. Die PB-Integer sind keine atomic Integer. Wenn man schreibt "a.i + 1", werden daraus trotzdem 3 ASM-Befehle generiert, nämlich Laden aus dem Speicher in ein Register, Wert erhöhen, und Zurückschreiben in den Speicher.

[ts-soft]

Naja, ich meinte auch nur die Lesezugriffe, hätte mich da wohl genauer ausdrücken müssen.

Danke für den Hinweis

[Lambda]

Danke für die Tipps, verwende jetzt doch ein Mutex und nutze, da höhere Priorität, beim Rendern im Thread die TryLockMutex Variante.

lg

[NicTheQuick]

Naja, ich meinte auch nur die Lesezugriffe, hätte mich da wohl genauer ausdrücken müssen.

Selbst da kann es passieren, dass zwei Threads aus ein und der selben Variablen unterschiedliche Werte lesen, da jeder Thread auf einem anderen Core laufen kann und jeder Core seinen eigenen Cache hat. Ist bei beiden Cores diese Variable im Cache und ändert sie einer von beiden Threads, wird sie normalerweise nicht direkt in den Arbeitsspeicher geschoben oder in einen höheren gemeinsamen Cache, sodass der andere Thread den aktuellen Wert bekommen würde. Deswegen kann man normalerweise Variablen als atomic deklarieren. Diese werden nämlich immer frisch aus dem Arbeitsspeicher geholt und nach Änderung zurück in ihn geschrieben.

[mk-soft]

Mal eine andere Idee...

Mit zwei Listen arbeiten. Eine Liste zum hinzufügen und die andere Liste zum rändern.
Der Thread zum Rändern sperrt kurz die Liste zum hinzufügen und übernimmt diese zur Liste zum Rändern.

FF

[DarkDragon]

Naja, ich meinte auch nur die Lesezugriffe, hätte mich da wohl genauer ausdrücken müssen.

Selbst da kann es passieren, dass zwei Threads aus ein und der selben Variablen unterschiedliche Werte lesen, da jeder Thread auf einem anderen Core laufen kann und jeder Core seinen eigenen Cache hat. Ist bei beiden Cores diese Variable im Cache und ändert sie einer von beiden Threads, wird sie normalerweise nicht direkt in den Arbeitsspeicher geschoben oder in einen höheren gemeinsamen Cache, sodass der andere Thread den aktuellen Wert bekommen würde. Deswegen kann man normalerweise Variablen als atomic deklarieren. Diese werden nämlich immer frisch aus dem Arbeitsspeicher geholt und nach Änderung zurück in ihn geschrieben.

Atomic? Volatile wäre das doch, was du eben mit dem "höheren, gemeinsamen Cache" und "frisch aus dem Arbeitsspeicher" meinst. Aber dann braucht man immer noch atomarität der Zugriffe (das entspricht quasi locks drumrum), da ja auch echt parallel damit operiert werden kann, wodurch die Aussage über atomic wieder richtig wird. Atomic sichert jedoch nur Einzelzugriffe ab!