In allen Programmbestandteilen ist die globale Variable bekannt. Beim betätigen der ESC-Taste oder einem Button wird die Variable auch gesetzt und in anderen parallel laufenden Funktionen ist sie ebenfalls richtig geändert. Der Thread läuft danach jedoch meist munter weiter. Manchmal hält er etwas später an und manchmal aber auch nicht.

...
for (...) {
  if (bAbortJob) { 
    ... 
    return;
  } 
  ...
}
...

Woran kann das liegen. Hatte jemand schon mal ein ähnliches Problem? Kann es sein, das die CPU die globale Variable nicht aus dem Speicher neu läd, sondern nur die aus dem Cache benutzt (die falsche)? Diese Methode läuft in anderen Programmen tadellos. Warum der Thread meist nach einiger Zeit doch abbricht kann ich mir nicht wirklich erklären.

Gruß
Trooper

Andererseits ist es davon abhängig was der Thread alles in einem Durchgang in der for-Schleife macht. Dann kann es etwas dauern, bis die if()-Abfrage wieder im nächsten Durchlauf dran kommt.

...
for (...) {
  if (bAbortJob) {
    ...
    return;
  }
  ... // <-- laaangsamer Codeabschnitt
}
...

Wenn die Ausführung grade in dem langsamen Codeabschnitt ist, kann es unter Umständen sehr lange dauern, bis die Variable wieder geprüft wird.

Sollte das nicht so sein, muss die Variable wohl doch irgendwo nicht richtig gesetzt worden sein bzw. wiedr zurückgesetzt. Dummerweise ist das ja gerade das Problem bei globalen Variablen, dass man sich nie sicher sein kann, wo diese nicht eventuell doch irgendwo falsch gesetzt werden.
Dass der alte Wert aus dem Cache falsch geladen wird, ist eigentlich auszuschließen, dann kannst du denk ich von einem Compilerbug ausgehen.

Wird dieses Event "gesetzt", dann bricht der Thread ab.

Aber wenn der Thread irgendwo innerhalb der for-Schleife beschäftigt ist, kann es eben dauern, bis das nächste mal die Abfrage nach dem Abbruch-Event durchgeführt wird. Man könnte dann zwischen den einzelnen Arbeitschritten (wenn es mehrere sind) immer wieder das Event (oder die Variable) abfragen, um auch zwischendurch abzubrechen (wenn möglich/sinnvoll).

Dass der alte Wert aus dem Cache falsch geladen wird, ist eigentlich auszuschließen, dann kannst du denk ich von einem Compilerbug ausgehen.

Zur Sicherheit kannste sie noch volatile machen. Damit sagst Du dem Compiler explizit, daß sie von anderen Threads aus geändert werden darf und der seine optimierenden Griffel davon fern halten soll.
Events sind gar nicht nötig, hier finde ich sie sogar unangebracht.

Events sind gar nicht nötig, hier finde ich sie sogar unangebracht.

Würdest Du (auch bei mehreren Threads?) mit globalen Abbruch-Variablen arbeiten? Oder welche Methode schlägst Du vor?

Lösungen wären:
Mutex
boost::atomic
ein von deiner Compilerimplementierung vorgesehener Mechanismus

Keine Lösung ist volatile, es sei denn, dein Compiler will das explizit so.

Lars

volkard schrieb:

Events sind gar nicht nötig, hier finde ich sie sogar unangebracht.

Würdest Du (auch bei mehreren Threads?) mit globalen Abbruch-Variablen arbeiten? Oder welche Methode schlägst Du vor?

Wenn sie nur rechnen würden, ja.
Tun sie aber nie. Da sie für den Benutzer Sleep oder recv oder sowas drin haben, oder von einer Pipe daten holen oder sonstwie halt gerne warten und die Variablenänderung nicht sehen würden, tue ich das Event mit in die Objekte von WaitForMultipleObjects oder select.

Events sind gar nicht nötig, hier finde ich sie sogar unangebracht.

volkard schrieb:

..., tue ich das Event mit in die Objekte von WaitForMultipleObjects oder select.

Huch?!

Also doch Events...?!

volkard schrieb:

Events sind gar nicht nötig, hier finde ich sie sogar unangebracht.

volkard schrieb:

..., tue ich das Event mit in die Objekte von WaitForMultipleObjects oder select.

Huch?!

Also doch Events...?!

Aber nicht wie bei Dir als Variable zweckentfremdet.

kann es eben dauern, bis das nächste mal die Abfrage nach dem Abbruch-Event durchgeführt wird

Wenn Du so programmieren willst, dann sind Events unangebracht.

Wenn die Variable ohne irgendeinen Synchronisationsmechanismus einfach nur so gesetzt wird, tritt genau der von dir beschriebene Effekt auf.

Lösungen wären:
Mutex
boost::atomic
ein von deiner Compilerimplementierung vorgesehener Mechanismus

Keine Lösung ist volatile, es sei denn, dein Compiler will das explizit so.

Lars

Sag mir einen Compiler, der es nicht so will.

Roger Wilco schrieb:

Also doch Events...?!

Aber nicht wie bei Dir als Variable zweckentfremdet.

kann es eben dauern, bis das nächste mal die Abfrage nach dem Abbruch-Event durchgeführt wird

Wenn Du so programmieren willst, dann sind Events unangebracht.

Warum als Variable zweckentfremdet? Ich würde das Event setzten, wenn der Thread abbrechen soll und sobald der Thread das Event durch WaitFor... "abfragt", dann bricht der Thread eben ab.

Haben wir uns falsch verstanden, oder mache ich etwas grundsätzliches verkehrt?

Edit: Du meinst, wenn der Thread eh ein Event-Handler (z.B. WaitFor...) besitzt, dann würdest Du mit einem Abbruch_Event arbeiten und wenn es nur eine stupide while()/for()-Schleife ist, dann mit einer globalen Abbruch-Variable?

manni66 schrieb:

Wenn die Variable ohne irgendeinen Synchronisationsmechanismus einfach nur so gesetzt wird, tritt genau der von dir beschriebene Effekt auf.

Lösungen wären:
Mutex
boost::atomic
ein von deiner Compilerimplementierung vorgesehener Mechanismus

Keine Lösung ist volatile, es sei denn, dein Compiler will das explizit so.

Lars

Sag mir einen Compiler, der es nicht so will.

gcc, VisualStudio

Lars

volkard schrieb:

manni66 schrieb:

Wenn die Variable ohne irgendeinen Synchronisationsmechanismus einfach nur so gesetzt wird, tritt genau der von dir beschriebene Effekt auf.

Lösungen wären:
Mutex
boost::atomic
ein von deiner Compilerimplementierung vorgesehener Mechanismus

Keine Lösung ist volatile, es sei denn, dein Compiler will das explizit so.

Lars

Sag mir einen Compiler, der es nicht so will.

gcc, VisualStudio

Lars

Früher hab ich globale Variablen so verwendet (viel mit MSVC) und es funktionierte. Was passiert schlimmstenfalls genau, wenn der Compiler so ist, wie Du sagst?

"...grade in dem langsamen Codeabschnitt ist..."
Das habe ich überprüft und ist nicht der Fall.

"...irgendwo wieder zurückgesetzt..."
Die Variable wird nirgendwo sonst zurückgesetzt/verändert.

"...volatile..."
Hatte ich auch bereits probiert - brachte nix.

@manni66
"Wenn die Variable ohne irgendeinen Synchronisationsmechanismus einfach nur so gesetzt wird, tritt genau der von dir beschriebene Effekt auf."
Und Warum?

Also gelöst ist das Problem noch immer nicht und ich verstehe nicht weshalb.

Gruß
Trooper

manni66 schrieb:

volkard schrieb:

manni66 schrieb:

Wenn die Variable ohne irgendeinen Synchronisationsmechanismus einfach nur so gesetzt wird, tritt genau der von dir beschriebene Effekt auf.

Lösungen wären:
Mutex
boost::atomic
ein von deiner Compilerimplementierung vorgesehener Mechanismus

Keine Lösung ist volatile, es sei denn, dein Compiler will das explizit so.

Lars

Sag mir einen Compiler, der es nicht so will.

gcc, VisualStudio

Lars

Früher hab ich globale Variablen so verwendet (viel mit MSVC) und es funktionierte. Was passiert schlimmstenfalls genau, wenn der Compiler so ist, wie Du sagst?

1. es funktioniert nicht (zuverlässig), oder schlimmer, auf Rechner A (deiner) ja, auf B (Kunde) nein
2. da der Compiler die Zugriffe nicht optimiert, sind sie langsamer (ist im im vorliegenden Code wohl unerheblich)

Lars

@manni66
"Wenn die Variable ohne irgendeinen Synchronisationsmechanismus einfach nur so gesetzt wird, tritt genau der von dir beschriebene Effekt auf."
Und Warum?

Weil die verschiedenen Prozessorkerne bei Multicore-Architekturen jeweils eine eigene Kopie der Variablen benutzen, und über die Änderung in einem anderen Kern nicht informiert werden.

Siehe auch: Programming with POSIX Threads, David R. Butenhof
oder die Seite von Herb Sutter (http://www.gotw.ca/)

Lars

Der da http://www.shafqatahmed.com/2008/01/multi-core-cach.html sagt, daß das auf x86 und x64 kein Problem wäre.

Na, wie gut, daß wie trooper zum Ausprobieren bhaben.

@trooper: Wie willste deine atomics haben? Boost, linux oder WinAPI?

oder die Seite von Herb Sutter (http://www.gotw.ca/)

Solche nicht nachvollziehbaren Links kannste Dir auch sparen. Die belegen gar nichts.

Und es klappt jetzt nur verstehe ich nicht ganz warum.
Ich rufe eine externe Funktion auf, die als Rückgabewert diese ominöse globale Variable hat.

for (...) {
  if (isAborted()) {
    return;
  }
}

manni66 schrieb:

oder die Seite von Herb Sutter (http://www.gotw.ca/)

Solche nicht nachvollziehbaren Links kannste Dir auch sparen. Die belegen gar nichts.

Wenn du meinst ...

Lars

Es ist x86 unter Windows.

Und es klappt jetzt nur verstehe ich nicht ganz warum.
Ich rufe eine externe Funktion auf, die als Rückgabewert diese ominöse globale Variable hat.

for (...) {
  if (isAborted()) {
    return;
  }
}

Hast Du zufällig eine lokale Variable isAborted oder ein Attribut isAborted hier oder der Basisklasse angelegt?
Um nochmal auf die cache-Therie zu kommen, würde ein anderer Funktionsaufruf, sagen wir mal

cout<<"";

oder

CloseHandle(INVALID_HANDLE_VALUE);

vor dem if es auch reparieren?

Die passenden atomics wären glaube ich

LONG isAborted=0;//bool isAborted=false;
InterlockedOr(&isAborted,1);//isAborted=true;
if(InterlockedOr(&isAborted,0));//if(isAborted)

volkard schrieb:

manni66 schrieb:

oder die Seite von Herb Sutter (http://www.gotw.ca/)

Solche nicht nachvollziehbaren Links kannste Dir auch sparen. Die belegen gar nichts.

Wenn du meinst ...
Lars

Nicht wegen Sutters Glaubwürdigkeit, sondern weil Du nicht die konkrete Unterseite nennst. Der schreibt nämlich viel.

bool isAborted(void) {
  return bAbortJob;
}

Es gibt keine andere lokale Variable bzw. Funktion, welche genauso heißt.
Im Algorithmus werden andere Funktionen aufgerufen (die Progressbar aktualisiert etc.). Ein cout<"" ändert da nichts.

manni66 schrieb:

volkard schrieb:

manni66 schrieb:

oder die Seite von Herb Sutter (http://www.gotw.ca/)

Solche nicht nachvollziehbaren Links kannste Dir auch sparen. Die belegen gar nichts.

Wenn du meinst ...
Lars

Nicht wegen Sutters Glaubwürdigkeit, sondern weil Du nicht die konkrete Unterseite nennst. Der schreibt nämlich viel.

Ja, und das sollte man in Bezug auf Threads auch (fast) alles lesen. Mit Threads schießt man sich sonst sehr schnell ins eigene Knie. Ist halt alles nicht so einfach ...

Lars