Hmm ich kann natürlich ein deepcopy verwenden, aber da ja der Filter normalerweise funktioniert, eben nur manchmal und nur einzelne Threads mal Unfug zurückkommt, denke ich dass es soweit funktioniert.

/edit: Achso es funktioniert bislang NUR weil ich vorher die alte Liste explizit lösche. Ich muss ...

@Blackjack Danky für den Tipp, das kannte ich bisher nicht und werde es ansehen.

Copy erzeuge ich mit dem copy- Modul (also copy.copy(p)...), weil ich später nämlich manche Partikel verdoppeln muss, per Referenz würde er ja dann zweimal das gleiche berechnen (bzw. an einem weiterrechnen).

@Llan:
Ist Dein logging threadsafe? Ansonsten hättest Du wohl das selbe Problem wie mit dem print.


Die Hilfe sagt "The logging module is intended to be thread-safe without any special work needing to be done by its clients. "


Steht iProc irgendwie in Beziehung zur Länge von partPartition ...

Hmm, also eigentlich nicht, bei der Berechnung jedenfalls agiert jeder unabhängig. Beim Aufsammeln nach dem join mache ich auch Kopien der Partikel und speichere die zurück.
Aber ich mache keine Kopien bevor ich auf die Threads aufteile. Das heißt, der Thread arbeitet nur per Referenz mit den ...

Aber auch wenn ich zuerst alle Threads joine, dann nochmal durchgehe und alles ausgebe (ich verwende sowieso kein print, sondern ein logfile), dann sind die Werte die dann in den Partikeln drinstehe einfach falsch, auch für die weiteren Berechnungen. Kann es trotzdem daher kommen?

Wie weight berechnet wird ist irrelevant. Es ist einfach ein float, und im Thread-print wird es korrekt ausgegeben.

Hallo,

ich habe Probleme mit einer Anwendung, in der ich Threads verwende um AUfgaben verteilt berechnen zu lassen. Die verteilte Berechnung funktioniert so, dass ich einen Thread abspalte der dann durch mpiexec auf anderen Prozessoren rechnet. Nach Ende der Berechnungen sollen durch ein join die ...