¿Es seguro .NET System.Net.CookieContainer?

Question

1. ¿Es seguro el subproceso System.Net.CookieContainer de clase .NET? - Actualización: Llave en mano respondida--
2. ¿Hay alguna manera de garantizar la seguridad de subprocesos a las variables que se modifican durante las solicitudes asincrónicas (es decir, HttpWebRequest.CookieContainer)?
3. ¿Hay algún atributo para resaltar las clases de seguridad de subprocesos? - Actualización: Si se describe seguridad de subprocesos en MSDN, entonces probablemente no tengan un atributo para esto -
4. ¿Están seguras todas las clases de .NET? - Actualización: Marc answered--

Hago estas preguntas porque uso el CookieContainer en las solicitudes asíncronas en un código multiproceso. Y no puedo poner una solicitud asincrónica dentro de un bloqueo. Tal vez tendré que usar readonly "variables" (o tipos inmutables) como en F #, ¿verdad?

Answer 1

No, no todas las clases .NET son seguras para hilos. De hecho, muy pocos tienen la necesidad de serlo. En general, los miembros estáticos deberían ser seguros para subprocesos, pero eso es todo.

Los objetos inmutables/semiinmutables son automáticamente seguros para subprocesos (esto incluye cosas como XslTransform, etc.) y hay unos pocos casos mutables (como contenedores roscados) donde puede esperar que las cosas sean seguras para hilos. MSDN declara seguridad de subprocesos para cada clase.

No espero que un contenedor de cookies sea seguro para subprocesos, por lo que probablemente tendrá que sincronizarlo usted mismo.

(actualizado)

Re su segundo punto; exactamente en qué variables estás pensando? Sus propias variables de estado local no se actualizarán directamente durante la solicitud asíncrona, por lo que simplemente le corresponde sincronizar el acceso al preparar las solicitudes al procesar las respuestas. Más comúnmente, a través de un Monitor - es decir

lock(syncLock) { 
    // prepare request from (synchronized) state 
    req.Begin{...} 
} 

y luego en la devolución de llamada

lock(syncLock) { 
    // ...read values from request... 
    // ...update local state... 
} 

Dónde syncLock es sólo un objeto de bloqueo (tal vez retenido contra una instancia):

private readonly object syncLock = new object(); 

Answer 2

Desde el horses mouth:

Seguridad para subprocesos

estáticos públicos (Shared en Visual Basic) de este tipo son seguros para subprocesos. No se garantiza que ningún miembro de instancia sea seguro para subprocesos.

Editar:

Se puede poner un candado en torno a acciones que modifican los miembros de instancia.

Answer 3

Todo Microsoft garantiza que las clases estáticas en el marco .NET son seguras para hilos.

Puede verificar esto utilizando Reflector.

Answer 4

Sólo una nota, una página web envía una lista de cookies modifed como parte de su respuesta HTTP. Modificar el CookieContainer después de que se haya enviado la respuesta no logrará nada. Simplemente modificará la colección de cookies de una solicitud de página que ya no existe.

Answer 5

mi punto de vista (con la ayuda del reflector), CookieContainer utiliza internamente cerraduras para acceder a sus miembros, por lo que debería ser seguro para subprocesos, a pesar de la documentación.

Por cierto, no tiene miembros estáticos públicos en absoluto. Entonces me parece que la documentación proporciona solo un aviso estándar.