ich habe ein Multithreading Problem, vielleicht verstehe ich auch nur was falsch, aber so langsam bin ich mir da nicht mehr sicher, vielleicht ist es auch nur ein kleiner Fehler (den ich mal wieder nicht so schnell sehe. Das ganze Programm kann ich leider nicht hochsetzen, aber bei Nachfragen kann ich schon Teile mal reinsetzen.

So jetzt erst mal zu mein Problem:

Mein Programm funktioniert kurioser Weise völlig korrekt, wenn ich viele Sachen in Dateien schreibe (was mich am meisten zum verzweifeln bringt). Nehme ich diese aber heraus ensteht ein Speicherzugriffsfehler. So jetzt möchte ich erst mal mein Verständnis von Threads geben. Threads sind Teile von Prozessen, die aber Zugriff auf die Daten des Hauptprozesses haben (was bei mir ja auch funktioniert). Mutexe sperren bei mir den Zugriff auf jede Schreibaktion auf die Festplatte (trotz unterschiedlicher Dateien) oder auf dem Bildschirm. Leseoperationen auf globale Variablen, an den Thread übergebene Variablen oder im Thread erstellten Variabeln werden nich geschützt. Das ist doch korrekt so, oder??

Diese Thread-Funktion wird jetzt etwa einmal oder bis zu 16 mal gleichzeitig durchlaufen. Wenn nur ein Thread durchläuft funktioniert es einwandfrei, laufen mehr Threads (meist 16) kommt es zum Speicherzugriffsfehler. Wo der Fehler aber genau liegt kann ich schlecht definieren. Habe das Programm auch schon mehrmals verändert, hatte mal keine globalen Variabeln, habe das Thread-Programm verändert, aber nichts hat geholfen. Kann mir jemand helfen? Wie gesagt, denke Programmstücke kommen während des Gesprächs!??!

LG andy

unsigned int helper, helpen;

unsigned int* helping;

TrickyThing thread = ((TrickyThing)args);

set<vector<unsigned int> > setA;

vector <unsigned int> helps(4);

pthread_mutex_lock(&mutex);

Matrix Ergebnis(thread.path.c_str());

pthread_mutex_unlock(&mutex);
int q = 0;
for (int i=0; i<Ergebnis.get_row();++i){
for (vector<unsigned int*>::iterator k = variabel.begin(); k != variabel.end(); ++k){
helping = *k;
if (helping[1]!=Ergebnis.get_element(i, thread.column)) continue;
if (setA.size()>50000000){
if (thread.column==0){
helper=Ergebnis.get_element(i-1, 1);
helpen=Ergebnis.get_element(i, 1);
}else{
helper=Ergebnis.get_element(i-1, 0);
helpen=Ergebnis.get_element(i, 0);
}
if (helper!= helpen){
pthread_mutex_lock(&mutex);
if (q==0){
outfile_set(setA,(thread.secondpath).c_str(),1);
q=1;
}else{
outfile_set(setA,(thread.secondpath).c_str(),0);
}
setA.clear();
cout << thread.message << " calculates " << i << " of " << Ergebnis.get_row() << " rows..."<< endl << endl;
pthread_mutex_unlock(&mutex);
}
}
for (int l=1; l<=helping[0]; ++l){
for (int m=0; m<4;++m){
if(thread.column==m){
helps[m] = helping[l];
} else {
helps[m] = Ergebnis.get_element(i, m);
}
}
setA.insert(helps);
}
}
}

pthread_mutex_lock(&mutex);

if (q==0){
outfile_set(setA,(thread.secondpath).c_str(),1);
}else{
outfile_set(setA,(thread.secondpath).c_str(),0);
}

remove (thread.path.c_str());
pthread_mutex_unlock(&mutex);
setA.clear();

pthread_exit (0);

}

edit: nur um dem augenkrebs vorzubeugen und es für etwaige helfer lesbarer zu gestalten. ich selbst hab' heute nacht aber keinen drang mehr, mich da durchzuwurschteln

Also es wird eine Matrix aus einer Datei eingelesen, dessen Pfad ich durch den Threadaufrufer übergebe. Dieses Angabe und noch mehr befinden sich im struct Trickything. Dann wird die Matrix, die immer aus vier Zahlen pro Reihe besteht, pro Spalte aufgelöst. Ich habe einen Container variabel der Varianten einer Zahl beinhaltet, jede Zeile, in der die Zahl in der aktuellen Spalte vorkommt, wird eine identische Zeile mit den Varianten erstellt. Die Übergabe der Daten sind völlig korrekt, die Funktion selber ist auch korrekt, es lief auch bei Multithreading korrekt, nur wenn ich die Funktion mehrmals hintereinander aufrufe, entsteht ein Speicherzugriffsfehler. Und da wäre ich um Eure Hilfe dankbar?

nenn mal deine variablen so um dass man weiss wozu sie gut sind, mach ein paar kommentare rein was der code tut, und dann poste das ganze nochmal mit den relevanten stellen des restlichen programms.
vielleicht tut es sich dann jmd. an dein programm anzugucken.

und bitte schreib doch netterweise dazu WO genau es das programm zerreisst. wenn du das nicht weisst ist das gleich deine nächste aufgabe: finde es raus. genau dafür gibt es debug builds und debugger.

am ende der routine machs du ja sowas:

remove (thread.path.c_str());

ist das nich kritisch wenn diu

thread.path.c_str();

in mehren trhead verwendest?

nur ne vermutung

Leseoperationen auf globale Variablen, an den Thread übergebene Variablen oder im Thread erstellten Variabeln werden nich geschützt. Das ist doch korrekt so, oder??

globale Variablen ... wenn sie read only sind, also nicht veraendert werden waehrend ein thread laeuft.
an den Thread übergebene Variablen ... wenn sie per-value uebergeben wurden bzw aus anderen threads nicht schreibend referenziert werden
Thread erstellten Variabeln ... wenn es keine 'static' und keine an andere threads weitergegebene variablen sind.

hmm was machst du denn mit den pfaden? welche du über die Trickything struktur übergibst? sind diese konstant?

Sind von Thread zu Thread unterschiedlich, deswegen gibt es beim remove wohl kein Problem!

globale Variablen ... wenn sie read only sind, also nicht veraendert werden waehrend ein thread laeuft.
an den Thread übergebene Variablen ... wenn sie per-value uebergeben wurden bzw aus anderen threads nicht schreibend referenziert werden
Thread erstellten Variabeln ... wenn es keine 'static' und keine an andere threads weitergegebene variablen sind.

Genau so verstehe ich das auch. Lese die Variablen auch nur!!

Wobei man auf den Inhalt der Ausgaben mit printf und cout nicht zuviel geben sollte. Wenn mehrere Threads gleichzeitig darauf zugreifen wird's Buchstabensuppe

deswegen erwähnte ich ja eine möglichkeit wie man gezielt nur einen thread definieren kann, der debugausgaben macht

ich gebe zu thread debugging isdt nicht das einfachste, aber fang doch bitte einfach mal ein mit printf() oder cout zu arbeiten.

Das nennt sich auch Shotgun Debugging und ist ein beliebtes AntiPattern.

@OP:
Da du anscheinend unter einen unixoidem BS arbeitest, versuch mal helgrind aus der Valgrind-Suite. Die anderen Tools wie z.B. memcheck können dir auch helfen Fehler zu finden, wenn Speicherzugriffsfehler vorkommen.

Du solltest außerdem z.B. globale Variablen, übergebene Variablen etc., die von mehreren Threads gelesen werden und sich potenziell ändern können, mit volatile qualifizieren. Das hält den Compiler von gefährlichen Optimierungen (Annahmen über Unveränderbarkeit) im Multithreading Bereich ab.

Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable,[...]

Hiermit meine ich natürlich nur die Stack-Variablen die nicht an andere Methoden übergeben werden.

Tippgeber schrieb:

Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable,[...]

Hiermit meine ich natürlich nur die Stack-Variablen die nicht an andere Methoden übergeben werden.

Und für wie wahrscheinlich hältst du es, dass der Fehler nach Änderungen in der Synchronisierung noch auftritt "Der Versuch verändert das Experiment"...

Tippgeber schrieb:

Tippgeber schrieb:

Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable,[...]

Hiermit meine ich natürlich nur die Stack-Variablen die nicht an andere Methoden übergeben werden.

Und für wie wahrscheinlich hältst du es, dass der Fehler nach Änderungen in der Synchronisierung noch auftritt "Der Versuch verändert das Experiment"...

man passt die Umgebung Schrittweise wieder der alten an

man passt die Umgebung Schrittweise wieder der alten an

Super Idee. Und was ist, wenn das Problem nur in der ursprünglichlen Umgebung auftritt - wie es bei Multithreadingfehlern sehr häufig der Fall ist? Genau das ist Shotgun Debugging.

idea schrieb:

man passt die Umgebung Schrittweise wieder der alten an

Super Idee. Und was ist, wenn das Problem nur in der ursprünglichlen Umgebung auftritt - wie es bei Multithreadingfehlern sehr häufig der Fall ist? Genau das ist Shotgun Debugging.

Während du noch da sitzt und das Problem errätst haben andere das Problem mit ihrer Shotgutn längst erlegt

Hast du meinen Beitrag weiter oben gelesen? Race-Condition-Profiler? Verändert zwar auch das Experiment, aber nicht den ursprünglichen Code. Und zeigt dir auch artig mögliche Race-Conditions an, nicht nur tatsächlich aufgetretene. Und - ist ein systematisches und zielgerichtetes Vorgehen, anstatt wild, nach eigenem Gutdünken irgendwo Code einzustreuen, der den ursprünglichen Fehler vielleicht unauffindbar macht. Aber anscheinend bevorzugst du letztere Variante.