class DATA{

double dtime;
public:

double GetTime(){

 //LOCK
 return dtime;
 //UNLOCK
}

};

Un ein anderer Thread liest ab und zu diesen wer mit GetTime().

Ist unbedingt notwendig das ich den wert sperre wenn ich lese? Auser das ein verrückter wert raus komemn kann beim lesen, kann es keinen absturz geben oder?

http://msdn2.microsoft.com/en-us/library/ms684122.aspx <- könnte dich evtl. interessieren.

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?

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.

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

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

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.

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.

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.