Gibt es eine einfache Methode für den Zugriff auf benutzerdefinierte System.Configuration-basierte Konfigurationsdaten über eine thread-sichere Schnittstelle, ohne dass jeder Ausführungskontext Konfigurationsinformationen laden / neu laden muss, was rechenintensiv wäre?
System.Configuration-Klassen sind, wie die meisten (alle?) anderen Klassen in der .Net-Bibliotheksdokumentation von Microsoft, mit den folgenden Thread-Sicherheitsinformationen versehen:
Alle öffentlichen statischen Member (Shared in Visual Basic) dieses Typs sind threadsicher. Alle Instanzmitglieder sind nicht garantiert threadsicher.
Wenn ich dies lese, dürfen die ConfigurationSection -Objekte, die von ConfigurationManager.GetSection(string) und anderen ähnlichen Methoden (z. B. OpenExeConfiguration(string exePath).GetSection(string) ) zurückgegeben werden, nicht als threadsicher angenommen werden und sollten daher nicht von mehreren Ausführungskontexten verwendet werden. Dies verbietet das Speichern eines ConfigurationSection in einem Singleton, das ansonsten threadsicher wäre, da der Zugriff auf das Abschnittsobjekt zwar sicher ist, die Elemente auf dem Objekt jedoch nicht sicher sind.
Bei mehreren Aufrufen von GetSection ist jedoch wahrscheinlich eine erneute Analyse der Konfigurationsdateien und das Zuweisen neuer ConfigurationSection -Instanzen erforderlich, was zu einem hohen Aufwand führt, da sich die Konfiguration nach der Initialisierung wahrscheinlich nie ändert. Durch das Kopieren der Konfigurationsdaten in ein anderes threadsicheres Objekt scheint einer der Hauptvorteile der Verwendung des integrierten Konfigurationspakets von vornherein zunichte gemacht zu werden (einfacher Zugriff auf typkonvertierte und validierte Konfigurationsinformationen ohne viel Standard) Code).
Also, gibt es eine Möglichkeit, System.Configuration threadsicher zu verwenden, ohne auf übermäßiges Parsen und Zuweisen von Konfigurationsabschnitten zurückzugreifen? Die Implementierung Ihrer eigenen ConfigurationSection befreit Sie von der fehlenden Garantie von Microsoft, obwohl Sie über die System.Configuration -Schnittstellen darauf zugreifen (und wenn ja, wie würden Sie es implementieren, um threadsicher zu sein, wenn Sie auf die Basis zugreifen Der Indexer von ConfigurationSection wird für den Zugriff auf die konfigurierten Daten benötigt)?
Die von GetSection zurückgegebene Instanz ist nicht Thread-sicher. Das bedeutet, dass Sie einen Sperrcode hinzufügen müssen, um ihn in Ihrem Singleton zu verwenden.
Bei mehreren Aufrufen wird die Datei nicht erneut analysiert, es sei denn, die Datei wurde geändert. Die Daten werden im Speicher zwischengespeichert.
Ihr Threadsicherheitsproblem wird einfach durch Sperren gelöst (ich bin mir nicht sicher, ob Sie das tun müssen, es sei denn, Sie ändern die Konfiguration zur Laufzeit) und es gibt kein Performance-Problem.
ConfigurationManager.GetSection (string) ist ein öffentliches statisches Member, und da msdn angibt 'Alle öffentlichen statischen (in Visual Basic freigegebenen) Member dieses Typs sind Thread-sicher', können Sie davon ausgehen, dass sie sicher zu verwenden sind.
Was die Leistung anbelangt, würde ich davon ausgehen, dass MS es schon ziemlich effizient gemacht hat und einfach ihre Funktionen so verwendet, wie es ist. Denken Sie daran: vorzeitige Optimierung ist die Wurzel des Bösen.
Tags und Links .net c# multithreading system.configuration