Ich habe einen Teil von boost - die ibeta_inv-Funktion - in eine .Net-64-Bit-Assembly kompiliert und es funktionierte großartig, bis ich anfing, es aus mehreren Threads aufzurufen. Dann gibt es gelegentlich falsche Ergebnisse zurück.
Ich habe es mit diesem Code (C ++ / CLI) erfüllt:
%Vor%Hat das jemand schon mal versucht?
Ich habe es NICHT außerhalb von .Net versucht, also weiß ich nicht ob das der Grund ist, aber ich verstehe wirklich nicht warum, da es super single threaded funktioniert.
Verwendung (C #):
%Vor%UPDATE: Wie in meinen Kommentaren unten zu sehen ist - bin ich mir überhaupt nicht mehr sicher, dass dies ein Boost-Problem ist. Vielleicht ist es ein seltsamer PLinq zu C ++ / CLI Bug ??? Ich bin beschuldigt und werde später mit mehr Fakten zurückkehren.
Ich habe einen Teil des Boosts in einem C ++ / CLI 64bit-Projekt gekapselt und benutze es genau wie du aus C #.
Also habe ich Ihre C ++ - Klasse in meinen eigenen Boost-Wrapper eingeschleust und diesen Code dem C # -Projekt hinzugefügt:
%Vor%Und es wird einfach "für immer" ausgeführt. Die parallelen Ergebnisse sind zu jeder Zeit den sequentiellen Ergebnissen gleich. Keine Threadunsicherheit hier ...
Darf ich vorschlagen, dass Sie eine neue Kopie von Boost herunterladen und sie in ein komplett neues Projekt einbinden und ausprobieren?
Ich bemerke auch, dass Sie Ihr Ergebnis "BoostResult" genannt haben ... und erwähnen Sie in den Kommentaren etwas über "unsere aktuelle Implementierung". Was genau vergleichen Sie Ihr Ergebnis gegen? Was ist Ihre Definition von "richtig"?
Es ist wichtig, dass die Klasse Val threadsafe ist.
Ein einfacher Weg, um sicherzustellen, dass es unveränderlich ist, aber ich sehe, dass Sie auch BoostResult haben, das geschrieben werden muss. Das muss volatile sein oder eine Form der Sperrung haben.
Lock-Version: (siehe diese Frage , um zu bestimmen, welche für Ihre Zwecke am besten geeignet ist Anwendung)
%Vor%Und wenn Sie denken, dass 6 Millionen Sperren langsam sein werden, versuchen Sie es einfach:
%Vor%