Hilo de seguridad en el uso del Sistema.Configuración

Question

Hay un método fácil de acceder a Sistema personalizado.Configuración de la base de datos de configuración a través de un hilo de seguridad de la interfaz sin necesidad de que cada contexto de ejecución de la carga/recarga de la información de configuración que sería computacionalmente pesadas?

Sistema.Configuración de clases, como la mayoría (todos?) otras clases en el de Microsoft .Red de documentación de la biblioteca, se anotan con el siguiente hilo-información de seguridad:

Cualquier público estáticos (Compartidos en Visual Basic) de los miembros de este tipo son seguros para subprocesos.Los miembros de instancia no están garantizados para ser seguro para subprocesos.

Por mi lectura de esta, la ConfigurationSection los bienes devueltos a partir de la ConfigurationManager.GetSection(string) y otros métodos similares (por ejemplo, OpenExeConfiguration(string exePath).GetSection(string) no debe ser asumida como hilo de seguridad y por lo tanto no debe ser usado por múltiples contextos de ejecución.Esto prohíbe el almacenamiento de un ConfigurationSection en un singleton que de lo contrario sería subprocesos porque mientras que el acceso a la sección de objetos puede estar seguro, los miembros sobre el objeto en sí no son seguros.

Varias llamadas a GetSection, sin embargo , es probable que requieren re-análisis de los archivos de configuración y la asignación de nuevas ConfigurationSection de los casos que se tiene una sobrecarga alta teniendo en cuenta la configuración no es probable que alguna vez cambiar después de la inicialización.Además, la copia de los datos de configuración en otro objeto que se ha hecho thread-safe parece para derrotar a uno de los principales beneficios del uso de la incorporada en el paquete de configuración en el primer lugar de fácil acceso para el tipo de conversión y validado la información de configuración sin mucho código repetitivo).

Así, hay una manera de utilizar System.Configuration en un hilo de manera segura sin tener que recurrir a un exceso de análisis y asignación de secciones de configuración?¿La implementación de su propio ConfigurationSection libre a usted de la falta de garantía proporcionada por Microsoft, aunque se esté accediendo a ella a través de la System.Configuration interfaces (y si es así, ¿cómo se va implementar ser seguro para subprocesos cuando el acceso a la base de ConfigurationSection's indizador es necesaria para acceder a los datos configurados)?

Answer 1

La instancia regresó de GetSection no es thread-safe.Eso significa que usted necesita para añadir un código de bloqueo en el fin de usarlo en su singleton.

Varias llamadas no volver a analizar el archivo, a menos que el archivo ha cambiado.Los datos se almacenan en caché en la memoria.

El hilo de seguridad problema se resuelve fácilmente mediante el uso de bloqueo (no estoy seguro de que usted necesitará, a menos que usted está cambiando la configuración en tiempo de ejecución), y no hay ningún problema de rendimiento.

Answer 2

ConfigurationManager.GetSection(cadena) es un establecimiento público de miembro estático, y desde msdn de los estados público estáticos (Compartidos en Visual Basic) de los miembros de este tipo son seguros para subprocesos', usted puede asumir que es seguro de usar.

Como para el rendimiento, yo estaría dispuesto a asumir que MS ha hecho bastante eficiente ya y sólo tiene que utilizar sus funciones, como es.Recuerde:prematuro de la optimización es la raíz del mal.