Threads Parameter lesen ohne Syncronisation

dot

wenn das leben deines programms am richtigen wert dieser variable hängt, dann schon

BorisDieKlinge

ne der wert wird gelesen und visualisiert, wenn der wert falsch oder daneben sist ,wird halt was falschen angezeigt... also nich lebensabhängig:)

schau aber scheiße aus

Badestrand

Eigentlich dürfte der doch nicht mal einen falschen Wert annehmen, oder? Schließlich müsste die double-Variable ja mit einem Rutsch (einer Asm-Anweisung) beschrieben werden..? Oder wird die Thread-Ausführung auch manchmal mitten in einer Anweisung unterbrochen?

ghorst

eigentlich kann nicht während der abarbeitung eines befehles unterbrochen werden, daher sollte der zugriff auf das double eigentlich atomar sein.
allerdings verstehe ich nicht, warum du dafür eine klasse benutzen willst. ein

extern const volatile double dtime;

an der stelle, an der du die zeit brauchst, wäre doch die sinnvollere variante für das speichern der zeit, oder?

taff

da ich ein ähnliches problem habe bzw. dazu was möchte, meine frage dazu:

ich habe mir testhalber 4 threads erzeugt die in einem skalaren datentyp (bool, int, char, float) gleichzeitig reinschreiben und lesen. ich bekomme dabei keinerlei abstürtze, etc.
braucht man für skalare datentypen kein locking oder reicht es hier aus, wenn ich die varialbe als volatile behandle?
es ist so, dass einen boolischen wert ständig durch einen thread abfrage und ein anderer thread ändert diesen wert ab und zu. nun stellt sich für mich die frage in wie weit, man sich verlassen kann, dass es hier zu keinem absturz kommt? ich möchte einfach verhindern, dass ich eine größere struktur in dem dieser bool drinnen ist, ständig locken muss.

danke für die auskunft und hilfe.

simon.gysi

das wird eine lustige threading - volatile diskussion...
simon

taff

simon.gysi schrieb:

das wird eine lustige threading - volatile diskussion...
simon

danke für die wortspende, dein beitrag hilft mir sehr weiter

Ich bin jetzt kein ASM-Guru, aber ich bin mir recht sicher, dass das Kopieren eines 64Bit Floats nicht in einem Rutsch geschieht bei einer x86 (32Bit) Architektur.

Schau doch mal in die winapi, die haben ja für viele Sachen atomare Operationen, d.h. du musst dich nicht um das Locking kümmern, du ruftst einfach diese Methoden auf und die erledigen, dann die Arbeite ohne Unterbrechung, als ob diese Operation atomar wäre.

hustbaer

ein zugriff auf ein double ist nicht so ohne weiteres atomar, der wert kann also kompletter schrott sein.
und wenn man mit dem wert weiterrechnet könnte es auch sein dass irgendwo wegen des falschen wertes auf einmal ein signaling NAN rauskommt... je nach verwendeter plattform/CPU.

braucht man für skalare datentypen kein locking oder reicht es hier aus, wenn ich die varialbe als volatile behandle?

der standard garantiert hier nix, und solange man sich nicht auf eine plattform festlegt gibt es auch sonst keine garantien. d.h. du musst auch für typen wie char, short, int etc. locken. (ja, selbst char kann auf bestimmten plattformen probleme machen!)

volatile bringt auf bestimmten plattformen etwas, wenn diese ein bestimmten verhalten bezüglich volatile garantieren.

ganz allgemein kann man aber nichtmal bei einem volatile char davon ausgehen dass immer nur werte gelesen werden die auch irgendwann ein anderer programmteil so reingeschrieben hat. eine C++ implementierung dürfte z.B. ein char auf 2 CPU-worte aufteilen. der code um ein char zu schreiben würde dann 2 CPU werte lesen, anpassen, und wieder zurückschreiben. ein anderer thread könnte dann das char auslesen zu einem zeitpunkt wo ein CPU-wort schon auf einen neuen wert angepasst wurde, das 2. aber noch nicht.

----

@BorisDasTaschenmesser

wenn dein programm nicht gerade zig- bis hunderttausendmal pro sekunde auf den wert zugreift, dann mach es doch einfach mit locking. tut nicht weh. ehrlich.

simon.gysi

Unter Windows könnten zudem die InterlockedXXX Funktionen benutzt werden.
Simon

taff

hustbaer schrieb:

ein zugriff auf ein double ist nicht so ohne weiteres atomar, der wert kann also kompletter schrott sein.
und wenn man mit dem wert weiterrechnet könnte es auch sein dass irgendwo wegen des falschen wertes auf einmal ein signaling NAN rauskommt... je nach verwendeter plattform/CPU.

braucht man für skalare datentypen kein locking oder reicht es hier aus, wenn ich die varialbe als volatile behandle?

der standard garantiert hier nix, und solange man sich nicht auf eine plattform festlegt gibt es auch sonst keine garantien. d.h. du musst auch für typen wie char, short, int etc. locken. (ja, selbst char kann auf bestimmten plattformen probleme machen!)

volatile bringt auf bestimmten plattformen etwas, wenn diese ein bestimmten verhalten bezüglich volatile garantieren.

ganz allgemein kann man aber nichtmal bei einem volatile char davon ausgehen dass immer nur werte gelesen werden die auch irgendwann ein anderer programmteil so reingeschrieben hat. eine C++ implementierung dürfte z.B. ein char auf 2 CPU-worte aufteilen. der code um ein char zu schreiben würde dann 2 CPU werte lesen, anpassen, und wieder zurückschreiben. ein anderer thread könnte dann das char auslesen zu einem zeitpunkt wo ein CPU-wort schon auf einen neuen wert angepasst wurde, das 2. aber noch nicht.

----

@BorisDasTaschenmesser

wenn dein programm nicht gerade zig- bis hunderttausendmal pro sekunde auf den wert zugreift, dann mach es doch einfach mit locking. tut nicht weh. ehrlich.

danke für die ausführliche erklärung!!!
habe das ganze nun mit einem locking gelöst.

simon.gysi schrieb:

Unter Windows könnten zudem die InterlockedXXX Funktionen benutzt werden.Simon

leider nicht möglich -> linux.