Globale Variablen bei großen Programmen

trooper

Ich habe einen Code für ein Programm bekommen wo ein langer Job über das setzten einer globalen Variable (Typ: bool) vorzeitig abgebrochen werden kann. Der Job ist in einem anderen Thread ausgelagert.

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

Roger Wilco

Globale Variablen haben den Nachteil, dass von überall darauf zugegriffen werden kann. Es kann sein, dass die Variable nach dem Setzen naschließend irgendwo wieder zurückgesetzt wird bevor der Thread sie in seiner if()-Anweisung abfragt.

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.

ipsec

Eine banale Erklärung wäre:

...
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.

Roger Wilco

Um das Problem der globalen Variable zu umgehen, wäre es sinnvoll ein Event-Handler in den Thread einzubauen. Dem Thread wird dann ein Abbruch-Event übergeben (bzw. der Thread erzeugt selber ein Event und gibt dieses an den Aufrufer zurück).

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).

volkard

ipsec schrieb:

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.

Roger Wilco

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 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

volkard

Roger Wilco schrieb:

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.

Roger Wilco

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...?!

volkard

Roger Wilco schrieb:

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.

volkard

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.

Roger Wilco

volkard schrieb:

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?

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

volkard

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?

trooper

Vielen Dank für eure Antworten erstmal.

"...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

volkard schrieb:

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?

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

Lars

trooper schrieb:

@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

volkard

Und der Thread endet nach längerer Zeit dann nur, weil der Thread immer wieder mal vom BS auf einen anderen Kern gelegt wird und irgendwann zufällig mal auf dem Kern landet, der die Änderung kennt?

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?

volkard

manni66 schrieb:

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

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

trooper

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;
  }
}