Thread 1:

while (running) {
   [...]
}

Thread 2 sagt irgendwann:

running = FALSE;

Ist das Threadsafe, oder brauche ich einen Mutex dafür? Es gibt ja nur einen Thread der schreibt. Hab irgendwo gelesen, dass der lesende Thread inkonsistente Daten lesen könnte, wenn ein lese und ein schreib Thread existieren. Ist das hier auch der Fall?

Schonmal danke, für eure Mühe!

Hab irgendwo gelesen, dass der lesende Thread inkonsistente Daten lesen könnte, wenn ein lese und ein schreib Thread existieren. Ist das hier auch der Fall?

wenn für's lesen oder schreiben mehr als eine asm-instruction nötig sind, dann brauchste 'nen lock, sonst sollte das ohne gehen...

dann isses bstimmt threadsafe.

volatile variablen können auch dann verändert werden, wenn das objekt const ist.

volatile variablen können auch dann verändert werden, wenn das objekt const ist.

du meinst mutable

volatile variablen können auch dann verändert werden, wenn das objekt const ist.

du meinst mutable

nein, er mein schon volatile. Das hat den 'nebeneffekt' das wert immer aus ram gelanden wird. Daruch kann man verhinder das der compiler so optimieret, das running in nem register liegen bleibt, da schneller, und so thread a niemals den wert von b sieht

volatile variablen können auch dann verändert werden, wenn das objekt const ist.

'volatile' sorgt nur dafür, dass die variable auch wirklich im speicher existiert d.h. es verbietet gewisse optimierungen. ...und 'const' ist auch nicht wirklich const

Maxi schrieb:

volatile variablen können auch dann verändert werden, wenn das objekt const ist.

'volatile' sorgt nur dafür, dass die variable auch wirklich im speicher existiert d.h. es verbietet gewisse optimierungen. ...und 'const' ist auch nicht wirklich const

Eine Member Variable einer Klasse liegt aber immer im Speicher. Aber volatile müsste hier doch trozdem gesetzt werden. Könnte ja sein, dass der Wert in einem Register zwischen gespeichert wird und nicht neugeladen wird. Oder?

ProgChild schrieb:

Hab irgendwo gelesen, dass der lesende Thread inkonsistente Daten lesen könnte, wenn ein lese und ein schreib Thread existieren. Ist das hier auch der Fall?

wenn für's lesen oder schreiben mehr als eine asm-instruction nötig sind, dann brauchste 'nen lock, sonst sollte das ohne gehen...

Das Problem ist noch weitergehend, für CPUs mit mehr als einem Hardware-Thread entstehen auch bei einzelnen Befehlen schon Inkosistenzen zwischen den verschiedenen Caches. Man kommt also nicht daran vorbei, den Cache nach dem Schreiben zu flushen und in anderen Caches diese Line neu einzulesen. Dies geschieht bei volatile-Variablen automatisch und ist u.U. sauteuer.

Auch spiegeln die ASM-Befehle nicht die reale CPU-Architektur wieder, die werden erst wieder in mehrere Mikrobefehle umgewandelt und auch intern parallelisiert ausgeführt. Vielleicht reicht allein das schon, um Probleme zu machen.

net schrieb:

Maxi schrieb:

volatile variablen können auch dann verändert werden, wenn das objekt const ist.

'volatile' sorgt nur dafür, dass die variable auch wirklich im speicher existiert d.h. es verbietet gewisse optimierungen. ...und 'const' ist auch nicht wirklich const

Eine Member Variable einer Klasse liegt aber immer im Speicher. Aber volatile müsste hier doch trozdem gesetzt werden. Könnte ja sein, dass der Wert in einem Register zwischen gespeichert wird und nicht neugeladen wird. Oder?

Muss nicht.

class foo
{
public:
   int val;
}

void func()
{
   foo f;
   for(int i=0;i<1000;i++)
   {
      f.val++;
   }
}

Was spricht dagegen eax als val zu betrachten und mit der schleife drüber zu laufen, ohne val im ram zu allozieren? Wird doch eh von keinem anderen gebraucht. Ok, in ist unwarscheinlich das der Fall eintritt aber es verbietet die keiner nur auf den registern, ohne push/pop oder ram, zu arbeiten so lange das verhanlten nach 'aussen' der norm entspricht.

Was spricht dagegen eax als val zu betrachten und mit der schleife drüber zu laufen, ohne val im ram zu allozieren? Wird doch eh von keinem anderen gebraucht.

Doch! Von dem anderen Thread.

Das Problem ist noch weitergehend, für CPUs mit mehr als einem Hardware-Thread entstehen auch bei einzelnen Befehlen schon Inkosistenzen zwischen den verschiedenen Caches. Man kommt also nicht daran vorbei, den Cache nach dem Schreiben zu flushen und in anderen Caches diese Line neu einzulesen. Dies geschieht bei volatile-Variablen automatisch und ist u.U. sauteuer.

Okay. Dann einen Mutex, volatile oder kein volatie und hoffen, das es klappt. Ich will nur eine Schleife, die in einem Thread abläuft, aus dem anderen beenden.

Optimizer schrieb:

Auch spiegeln die ASM-Befehle nicht die reale CPU-Architektur wieder, die werden erst wieder in mehrere Mikrobefehle umgewandelt und auch intern parallelisiert ausgeführt. Vielleicht reicht allein das schon, um Probleme zu machen.

Das war auch meine Überlegung. Es könnte ja sein, dass ein long byteweise zugewiesen wird, oder so...

ProgChild schrieb:

Hab irgendwo gelesen, dass der lesende Thread inkonsistente Daten lesen könnte, wenn ein lese und ein schreib Thread existieren. Ist das hier auch der Fall?

wenn für's lesen oder schreiben mehr als eine asm-instruction nötig sind, dann brauchste 'nen lock, sonst sollte das ohne gehen...

nicht auf einem Mehr-Prozessor-System (wobei die wahrscheinlichkeit dann wohl schon sehr gering sein dürfte)

nicht auf einem Mehr-Prozessor-System (wobei die wahrscheinlichkeit dann wohl schon sehr gering sein dürfte)

Was passiert denn im schlimmsten Fall auf einem Multiprozessor System? Wäre ja nicht schlimm, wenn der Thread erst etwas später abgebrochen wird, wenn die Chaches Synchronisiert werden.

Das folgende Programm sieht von außen ok aus (es sei denn man ist in Multithreading geschult):

extern "C" {
#include <pthread.h>
#include <unistd.h>
}

#include <iostream>

int flag = 0;

void * th(void *) {

        sleep(5);
        flag = 1;
        std::cout << "Counter is now " << flag << std::endl;
        return NULL;
}

int main() {

        pthread_t pid;
        pthread_create(&pid, NULL, th, NULL);

        unsigned int counter = 0;
        while (flag == 0) {
                ++counter;
        }
        pthread_join(pid, NULL);

        std::cout << "Counter: " << counter << std::endl;
}

Übersetzt mit

g++ -Wall -W -pedantic -pthread -O2 thread.C

läuft das Programm in eine Endlosschleife.

volatile hilft in diesem Beispiel, ist aber keine allgemeine Lösung. Siehe

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

rüdiger schrieb:

nicht auf einem Mehr-Prozessor-System (wobei die wahrscheinlichkeit dann wohl schon sehr gering sein dürfte)

Was passiert denn im schlimmsten Fall auf einem Multiprozessor System? Wäre ja nicht schlimm, wenn der Thread erst etwas später abgebrochen wird, wenn die Chaches Synchronisiert werden.

Verallgemeinert gesagt, sehen verschiedene Threads unterschiedliche Werte, weil jeder seinen eigenen Cache hat. Schreiboperationen sieht eine ganze Zeit lang nur der schreibende Thread selber. Das ist katastrophal.

Auch spiegeln die ASM-Befehle nicht die reale CPU-Architektur wieder, die werden erst wieder in mehrere Mikrobefehle umgewandelt und auch intern parallelisiert ausgeführt.

glaub' nicht. auch wenn's micro'code' heisst, so isses doch meistens so schnell wie ein elektron braucht um in's silizium einzudringen, damit hinten ein anderes rausfällt

rüdiger schrieb:

net schrieb:

ProgChild schrieb:

Hab irgendwo gelesen, dass der lesende Thread inkonsistente Daten lesen könnte, wenn ein lese und ein schreib Thread existieren. Ist das hier auch der Fall?

wenn für's lesen oder schreiben mehr als eine asm-instruction nötig sind, dann brauchste 'nen lock, sonst sollte das ohne gehen...

nicht auf einem Mehr-Prozessor-System (wobei die wahrscheinlichkeit dann wohl schon sehr gering sein dürfte)

jo, beim mehrprozzi haste das problem der verschachtelten bus-nutzung, da kann einer schon die speicherzelle verändert haben, während der andere erst den befehl decodiert hat. aber naja, ich meinte mit meinem posting das zeitscheiben-multitasking mit nur einer cpu. dabei ist ja ein asm-befehl nicht unterbrechbar...

jo, beim mehrprozzi haste das problem der verschachtelten bus-nutzung, da kann einer schon die speicherzelle verändert haben, während der andere erst den befehl decodiert hat. aber naja, ich meinte mit meinem posting das zeitscheiben-multitasking mit nur einer cpu. dabei ist ja ein asm-befehl nicht unterbrechbar...

Okay war jetzt das Resultat, dass ich volatile und Mutexe brauche, um sowas vernünftig zu realisieren, aber eig. volatile in der geg. Situation ausreicht?

net schrieb:

jo, beim mehrprozzi haste das problem der verschachtelten bus-nutzung, da kann einer schon die speicherzelle verändert haben, während der andere erst den befehl decodiert hat. aber naja, ich meinte mit meinem posting das zeitscheiben-multitasking mit nur einer cpu. dabei ist ja ein asm-befehl nicht unterbrechbar...

Okay war jetzt das Resultat, dass ich volatile und Mutexe brauche, um sowas vernünftig zu realisieren, aber eig. volatile in der geg. Situation ausreicht?

Du brauchst nur Mutexe. volatile ist nicht nötig. volatile alleine ist falsch.

Du brauchst nur Mutexe. volatile ist nicht nötig. volatile alleine ist falsch.

Warum? Solang die Synchronisation nur in eine Richtung geht und die Variable nur einmal dazu verwendet wird sehe ich kein Problem mit volatile.

wenn du windoofs hast, dann nimm dafür die 'InterlockedXXX' funktionen. die gehen auch bei mehreren prozessoren...

Nein, kein Windoof. Warum ich überhaupt darauf komme. Hab mir den Quelltext von XMMS angeschaut und da scheint es komplett ohne Mutex und ihne volatile gemacht worden zu sein...

Naja, ich werd dann wohl einfach zu sicherheit Mutexe setzten.

Danke an Alle.

Ponto schrieb:

Du brauchst nur Mutexe. volatile ist nicht nötig. volatile alleine ist falsch.

Warum? Solang die Synchronisation nur in eine Richtung geht und die Variable nur einmal dazu verwendet wird sehe ich kein Problem mit volatile.

Du hast doch selbst geschrieben, dass es stark systemabhängig sei.

Zunächst gibt es das Totschlagargument, dass C++ selbst kein Multithreading kennt und keine volatile Semantik für Multithreadingprogramme spezifiziert wurde. Aber soweit ich weiss haben auch Systeme mit Multithreading wie POSIX 1003.1 haben keine Semantik für volatile über Threads hinweg spezifiziert.

Dann kann man sich immer darauf zurückziehen, dass es Systeme geben kann in denen das nicht funktioniert. Nehmen wir mal ein System an, bei dem jedes Lesen aus dem Speicher von einem Schreiben mit dem gelesenen Wert gefolgt werden muss. Was passiert nun wenn der eine Thread den Wert ändert und der andere den gleichzeitig liest?

Auf so einem System kann die Singlethreadingsemantik von C++ problemlos implementiert werden.

Auf ner beliebigen Plattform kann man natürlich nicht viel mehr sagen, als daß man geeignet synchronisieren muß.