c# - safe - Qué significa "hilo seguro" en términos prácticos

thread safe list c#

Question

por favor tenga paciencia con mis preguntas de novato ...

Intentaba convertir PDF a PNG usando ghostscript, con ASP.NET y C #. Sin embargo, también leí que ghostscript no es seguro para subprocesos. Entonces mis preguntas son:

1. ¿Qué significa exactamente "ghostscript no es seguro para subprocesos" en términos prácticos? ¿Qué impacto tiene si lo uso en una aplicación web en vivo ASP.NET (aspx) con muchos usuarios simultáneos accediendo a él al mismo tiempo?

2. También leí en otro sitio que la característica principal de ghostscript ver. 8.63 es una representación multiproceso. ¿Esto significa que nuestro problema de hilo seguro ahora está resuelto? ¿Está seguro el hilo de Ghostscript ahora?

3. También estoy evaluando PDF2Image desde PDFTron, que se supone que es seguro para subprocesos. Pero la licencia por CPU no es barata. ¿Vale la pena pagar el dinero extra por "hilo seguro" frente a "no seguro"?

Answer 1

1. El hilo seguro básicamente significa que un trozo de código funcionará correctamente incluso cuando se acceda por varios hilos. Pueden ocurrir varios problemas si utiliza un código que no sea seguro para subprocesos en una aplicación con subprocesos. El problema más común es la inmovilización. Sin embargo, existen problemas mucho más nefastos (condiciones de carrera) que pueden ser un problema mayor porque los problemas de subprocesos son notoriamente difíciles de depurar.

2. No. El procesamiento multiproceso solo significa que GS podrá procesar más rápido porque está utilizando hilos para procesar (en teoría, de todos modos, no siempre es cierto en la práctica).

3. Eso realmente depende de lo que quiere usar su procesador. Si va a acceder a su aplicación con varios subprocesos, entonces, sí, tendrá que preocuparse de que sea segura para subprocesos. De lo contrario, no es un gran problema.

Answer 2

1) Significa que si comparte los mismos objetos o campos de Ghostscript entre varios hilos, se bloqueará. Por ejemplo:

private GhostScript someGSObject = new GhostScript();
...
// Uh oh, 2 threads using shared memory. This can crash!
thread1.Use(someGSObject);
thread2.Use(someGSObject);

2) No lo creo: la representación multiproceso sugiere que GS está usando internamente varios subprocesos para procesar. No aborda el problema de que GS no sea seguro para el uso de múltiples hilos.

3) ¿Hay alguna pregunta ahí?

Para proteger el hilo de GhostScript, asegúrese de que solo 1 hilo a la vez acceda a él. Puedes hacer esto a través de bloqueos:

lock(someObject)
{
   thread1.Use(someGSObject);
}
lock(someObject)
{
   thread2.Use(someGSObject);
}

Answer 3

Dado que una Colección, por ejemplo, no es segura:

var myDic = new Dictionary<string, string>();

En un entorno de múltiples hilos, esto arrojará:

string s = null;
if (!myDic.TryGetValue("keyName", out s)) {
    s = new string(''#'', 10);
    myDic.Add("keyName", s);
}

Como un hilo está trabajando tratando de agregar KeyValuePair al diccionario myDic, otro puede TryGetValue (). Como las colecciones no se pueden leer y escribir al mismo tiempo, se producirá una excepción.

Sin embargo, por otro lado, si prueba esto:

// Other threads will wait here until the variable myDic gets unlocked from the preceding thread that has locked it.
lock (myDic) {
    string s = null;
    if (!myDic.TryGetValue("keyName", out s)) {
        s = new string(''#'', 10);
        myDic.Add("keyName", s);
    }
} // The first thread that locked the myDic variable will now release the lock so that other threads will be able to work with the variable.

Entonces, de repente, el segundo hilo tratando de obtener el mismo valor de clave "keyName" no tendrá que agregarlo al diccionario ya que el primer hilo ya lo agregó.

En pocas palabras, la seguridad de los hilos significa que un objeto admite el uso de varios hilos al mismo tiempo o que bloqueará los hilos de manera adecuada para usted, sin tener que preocuparse por la seguridad de los hilos.

2. No creo que GhostScript ahora sea enhebrable. Principalmente está utilizando múltiples hilos para realizar sus tareas, por lo que ofrece un mayor rendimiento, eso es todo.

3. Dependiendo de su presupuesto y sus requisitos, puede ser digno. Pero si compila wrapper, tal vez solo podría bloquear () donde sea conveniente hacerlo, o si no usa multihilo usted mismo, definitivamente no vale la pena pagar por la seguridad del hilo. Esto significa solo que si su aplicación usa multihilo, entonces no sufrirá las consecuencias de que una biblioteca no sea segura para la lectura. A menos que realmente multihread, no vale la pena pagar por una biblioteca segura.

Answer 4

En general, es un término ambiguo.

Thread-Safety podría estar en el nivel conceptual, donde tiene la sincronización correcta de sus datos compartidos. Esto es usualmente, lo que significan los escritores de la biblioteca.

A veces, significa que la concurrencia se define en el nivel del idioma. es decir, el modelo de memoria del lenguaje admite simultaneidad. ¡Esto es complicado! porque como escritor de la biblioteca no puede producir bibliotecas simultáneas, porque el lenguaje no tiene garantías para muchas primitivas esenciales que se necesitan usar. Esto se refiere a los escritores de compiladores más que a los usuarios de la biblioteca. C # es seguro para subprocesos en ese sentido.

Sé que no respondí tu pregunta directamente, pero espero que eso ayude.

Answer 5

Es difícil encontrar una definición técnica precisa con la que todos estén de acuerdo.

Informalmente, "hilo seguro" simplemente significa "se comporta razonablemente bien cuando se lo llama desde múltiples hilos". El objeto no se bloqueará o producirá resultados extraños cuando se invoque desde varios hilos.

La pregunta que realmente necesita para obtener respuesta si tiene la intención de hacer una programación de subprocesos múltiples que involucre un objeto en particular es "¿cuál es el modelo de subprocesamiento esperado por el objeto?"

Hay un montón de diferentes modelos de subprocesos. Por ejemplo, el modelo de "rosca libre" es "haz lo que quieras de cualquier hilo, el objeto lo resolverá". Ese es el modelo más fácil para usted, y el más difícil para el proveedor de objetos.

En el otro extremo del espectro está el modelo de "un solo hilo": se debe acceder a todas las instancias de todos los objetos desde un solo hilo, punto.

Y luego hay un montón de cosas en el medio. El modelo "apartamento enhebrado" es "puede crear dos instancias en dos subprocesos diferentes, pero el hilo que use para crear una instancia es el hilo que siempre debe usar para llamar a los métodos en esa instancia".

El modelo de "alquiler enhebrado" es "puede llamar a una instancia en dos subprocesos diferentes, pero usted es responsable de garantizar que no haya dos subprocesos al mismo tiempo".

Y así. Averigüe cuál es el modelo de subprocesamiento que su objeto espera antes de intentar escribir código de subprocesamiento.

Answer 6

Si está utilizando ghostscript desde un objeto de shell (es decir, ejecutando una línea de comando para procesar el archivo), no será atrapado por problemas de subprocesamiento porque cada instancia que se ejecute lo hará en un proceso diferente en el servidor. Donde debe tener cuidado es cuando tiene un dll que está usando desde C # para procesar el PDF, ese código debería estar sincronizado para evitar que dos subprocesos ejecuten el mismo código al mismo tiempo.

Answer 7

Soy un desarrollador de Ghostscript y no repetiré la teoría general sobre seguridad de hilos.
Hemos estado trabajando para lograr que GS sea seguro para las hebras, de modo que se puedan crear múltiples "instancias" usando gsapi_new_instance desde un solo proceso, pero aún no lo hemos completado a nuestra satisfacción (lo que incluye nuestras pruebas de control de calidad).
La biblioteca de gráficos, sin embargo, es segura para subprocesos y la representación de subprocesos múltiples se basa en esto para permitirnos generar múltiples subprocesos para representar bandas de una lista de visualización en paralelo. El renderizado de subprocesos múltiples ha sido sometido a muchas pruebas de control de calidad y muchos licenciatarios comerciales lo utilizan para mejorar el rendimiento de las CPU multinúcleo.

Puedes apostar que anunciaremos cuando finalmente admitamos instancias múltiples de GS. La mayoría de las personas que desean usar GS actuales de aplicaciones que necesitan instancias múltiples engendran procesos separados para cada instancia, por lo que GS no necesita ser seguro para subprocesos. El GS puede ejecutar un trabajo como lo determinan las opciones de la lista de argumentos o la E / S se puede canalizar a / desde el proceso para proporcionar datos y recopilar resultados.