Globale Variablen bei großen Programmen

volkard

trooper schrieb:

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

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.

trooper

So hundert Prozent verstanden habe ich dich jetzt glaube ich nicht.
isAborted ist jetzt eine Funktion, welche als Rückgabe die globale Variable hat.

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.

volkard schrieb:

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

Ist im Standard nicht festgelegt, was volatile macht?

canthecan schrieb:

Ist im Standard nicht festgelegt, was volatile macht?

Es gibt im aktuellen Standard keine Aussage zu Threads, also auch nicht zum Verhalten von volatile. Genau genommen ist eine C++-Threadimplementierung wohl nicht standardkonform.

Lars

trooper

Das Projekt besteht aus vielen Modulen. Meine Vermutung war zunächst, dass es an der Projektgröße liegt, denn bei kleineren Projekten trat das Problem noch nie auf. Warum es mit dem kleinen Trick nun doch geht verstehe ich erst recht nicht und das wurmt mich.

trooper schrieb:

Das Projekt besteht aus vielen Modulen. Meine Vermutung war zunächst, dass es an der Projektgröße liegt, denn bei kleineren Projekten trat das Problem noch nie auf. Warum es mit dem kleinen Trick nun doch geht verstehe ich erst recht nicht und das wurmt mich.

Vielleicht wird die Speicherseite mit Variablen drin erst durch den Funktionsaufruf geladen und enthält dann den richtigen Wert.

Warum weigerst du dich, einen Mutex oder ähnliches einzusetzen?

Lars

Vielleicht liegt die Funktion in der korrekten Übersetzungseinheit udn greif daher auf die richtige Variable zu, was bei dem direkten Zugriff nicht der Fall war. Fehlendes extern, etc...

trooper

@manni66
"...Warum weigerst du dich, einen Mutex oder ähnliches einzusetzen?..."
Mach ich doch gar nicht und der Code ist auch nicht von mir. Zunächst wollte ich verstehen was genau da hängt. Es läuft zwar aber zufrieden bin ich mit der "Lösung" noch lange nicht.

@,,,
"volatile oder extern" sind definitiv nicht die Ursache für das Problem. Warum solle es dann auch mal laufen und mal nicht.

Aber vielen Dank für eure Hilfe.