2010-07-21 19 views
11

Tengo una aplicación multiproceso que analiza un poco de texto y necesita utilizar English Culture Info para analizar los números de este texto. Entonces, no quiero crear EngCulture cada vez que llamo a la función de análisis sintáctico. Actualmente paso el parámetro EngCulture pero no estoy contento con esto. Quiero definir EngCulture como un miembro estático, por lo que será compartido por subprocesos.CultureInfo thread safety

La documentación de msdn dice que "cualquier miembro público estático (compartido en Visual Basic) de este tipo es seguro para subprocesos. No se garantiza que ningún miembro de instancia sea seguro para subprocesos". Solo estoy usando la siguiente función, entonces ¿cómo podría saber si TryParse usa algún miembro de instancia de EngCulture o no?

public static CultureInfo EngCulture = new CultureInfo("en-US", false); 

void parser() 
{ 
    if (int.TryParse(value, NumberStyles.Number, EngCulture, out num))... 
} 

Respuesta

6

Intente utilizar CultureInfo.GetCultureInfo("en-US") que "recupera una instancia almacenada en caché, de solo lectura, de una cultura que utiliza el nombre cultural especificado".

http://msdn.microsoft.com/en-us/library/yck8b540.aspx

o hacer que su campo sea de sólo lectura por lo que no será necesario un bloqueo:

private static CultureInfo _culture = CultureInfo.ReadOnly(new CultureInfo("en-US")); 
+1

Sí, la promesa de solo lectura lo hace seguro para subprocesos. –

+2

¿'CultureInfo.ReadOnly' otorga garantías de seguridad de subprocesos? Porque [solo lectura e hilo seguro son diferentes] (http://blogs.msdn.com/b/ericlippert/archive/2011/05/23/read-only-and-threadsafe-are-different.aspx). –

+0

@ ta.speot.is: gran pregunta. Tenía curiosidad sobre eso yo mismo y [hice una pregunta al respecto] (http://stackoverflow.com/q/36766649/87698). – Heinzi

0

"Miembros" significa métodos más operadores más campos más propiedades. Está utilizando un miembro de instancia y, por lo tanto, debe usar un lock o buscar una forma alternativa de hacerlo.

Espero que ayude!

0

dos puntos:

no quiero crear EngCulture cada vez que llame a la función de análisis

no creo que esto realmente ser demasiado de una preocupación - CultureInfo s aren Va a ser especialmente grande, y en cuanto a rendimiento, los "incorporados" se almacenan en caché, por lo que todo lo que hace un new es recuperar un objeto existente. Por supuesto perfil y ver si realmente es un problema ...

¿cómo puedo saber si TryParse utiliza algún miembro de la instancia de EngCulture o no?

estaría muy sorprendidos al descubrir un método que aceptadas un CultureInfo y luego pasó a cambio que CultureInfo de ninguna manera. Aunque en realidad no son formalmente inmutables, los usaría (especialmente los "integrados") como si fueran inmutables, sin pensarlo dos veces.

Entonces, yo diría que tiene un new CultureInfo("en-US", false) estático y lo paso por alto, nada lo va a mutar, por lo que no surgen problemas de multi-threading.

+0

estoy dudando de que algún hilo lo ponga en un estado incoherente (en el medio de la lectura de una lista, etc.) mientras que otro intenta leerlo. entonces, si leer de él no era una gran preocupación, ¿por qué dijeron que no es seguro usar miembros de la instancia? – lockedscope

+0

@lockedscope Aplaudo su precaución. Aprendo de otras respuestas que los '' built-in '' CultureInfo's son de solo lectura, y en cualquier caso hay un método 'ReadOnly', por lo que uno de esos enfoques debería garantizar la seguridad. – AakashM

3

el fin de obtener hilos de seguridad puede crear una cultura de sólo lectura utilizando la estática CultureInfo.ReadOnly método:

public static CultureInfo EngCulture = CultureInfo.ReadOnly(
    new CultureInfo("en-US", false)); 
+1

No puedo encontrar en la documentación donde un '' CultureInfo 'de solo lectura es seguro para subprocesos. Ver mi comentario sobre la respuesta aceptada. –

1

puede configurar el CultureInfo de un hilo específico con System.Threading.Thread.CurrentThread.CurrentCulture = myCI; para que haga n No tiene que pasarlo cada vez que llame a una función.

Tenga en cuenta que el simple hecho de acceder a getters desde múltiples hilos no hará ningún daño en la mayoría de los casos si no modifica el objeto.