Mysteriöses Verhalten von DictionaryTKey, TSource

8

Ich arbeite an einem riesigen System basierend auf Asp.net MVC 3.0 und arbeite an Mono-2.10.8 (Windows 7).

Bis vor wenigen Tagen war alles in Ordnung.

Innerhalb meiner API habe ich mehrere Hilfsklassen, die Wörterbücher verwenden. Zum Beispiel, wie dieser:

%Vor%

Und zufällig erhalte ich Ausnahmen wie folgt:

%Vor%

Die meiste Zeit ist alles in Ordnung und KeyUtility funktioniert korrekt, aber in seltenen Fällen bekomme ich eine solche Ausnahme. Obwohl es wie ein Thread-Sicherheitsproblem aussieht, wird auf das Wörterbuch ReverseAlphabet immer nur zum Lesen und niemals zum Schreiben zugegriffen. Sobald es im statischen Konstruktor erstellt wurde, wird nur mit TryGetValue darauf zugegriffen. Wie ich aus MSDN Artikel verstehe, sollte es in diesem Fall threadsicher sein. Außerdem habe ich dieses Problem vorher nicht gesehen.

Was soll ich mir ansehen? Ich kann sogar keine Reproduktion erstellen, da ich absolut keine Ahnung habe, was falsch ist.

Mono-2.10.8 und ältere Versionen erwiesen sich mit Wörterbüchern als stabil. Ich benutze es seit ein paar Jahren intensiv und habe noch nie zuvor eine solche Ausnahme gesehen.

Wie behebt man das?

UPD:

Ich habe mich daran erinnert, dass das, was ich getan habe, in der Nähe der Zeit des Beginns von Problemen statisch mono mit meiner ausführbaren Datei verbunden ist (ich montiere Mono in meine Anwendung). Ich habe einfach Monoquellen heruntergeladen. Habe es ohne irgendwelche Änderungen kompiliert, außer dass ich die Ausgabe von libmono auf die statische Bibliothek eingerichtet habe. Ich habe auch mit libeay32 und sqlite3 verbunden. Alles Multithread (MT). Vielleicht könnte diese Änderung eine Anwendung beeinträchtigen? Leider kann ich dies nicht unter Standalone Mono überprüfen. Vorher habe ich alle Bibliotheken dynamisch verlinkt und alles war in Ordnung.

UPD2: Hier ist der Link zu den vollständigen Quellen: Ссылка

    
ILya 23.05.2012, 09:47
quelle

1 Antwort

12
  

was ich getan habe, ist statisch mono mit meiner ausführbaren Datei verknüpft

Du kennst das Problem schon, denke ich, das würde sicherlich mono brechen. Das Wichtigste, was nicht mehr passiert, wenn Sie es statisch verknüpfen, ist der DllMain () - Callback, den Windows ausführt, wenn ein neuer Thread im Prozess startet. So wird die CLR auf Threads aufmerksam, die verwalteten Code ausführen können. Statische Konstruktoren sind in der Tat ein wahrscheinlicher Fehlermodus, ein Thread muss blockiert werden, um irgendeinen Code in der Klasse auszuführen, bis die cctor () die Ausführung beendet hat. Die CLR kann das nicht, wenn sie den Thread nicht kennt.

Wenn Sie diese Funktion ausführen möchten, müssen Sie mindestens eine Alternative für den Aufruf mono_thread_info_attach () in Ihrer eigenen DllMain () - Funktion bereitstellen. Im Allgemeinen würde ich sagen, das war eine Optimierung zu viele.

    
Hans Passant 23.05.2012, 13:01
quelle