TCriticalSection vs Mutex

rolandoj · #1 12-03-2008

Hola,

Averiguando un poco sobre TCriticalSection encontré un comentario de que no debe usarse en DLLs, sino que en tal situación se deben usar Mutex; pero sin más detalles.

Alguién podría ilustrar esto ?. Es cierto ?. Por qué ?. Cual es la diferencia entre ambos mecanismos ?.

[cHackAll] · #2 12-03-2008

La principal diferencia es que el Mutex es un objeto del kernel y la sección crítica no lo es, lo que tiene como efecto que el Mutex sea accesible por distintos procesos, y el "CriticalSection" no;

Cita:

Empezado por http://msdn2.microsoft.com/en-us/library/aa910712.aspx

A critical section object protects a section of code from being accessed by more than one thread. However, a critical section is limited to only one process or DLL and cannot be shared with other processes.

Esto es corroborable con la forma de inicialización de ambos; para crear una sección crítica se utiliza la API InitializeCriticalSection, la cual inicializa una estructura COMPLEJA. Dicha estructura al pertenecer al proceso el cual la ha iniciado no puede ser compartida entre procesos.

Sin embargo la forma de inicialización de un Mutex (mediante la API CreateMutex), es con un nombre único y global en el sistema. Con dicha idea se puede usar el Mutex para tener una única instancia de una aplicación, lo que es imposible con una sección crítica.

Con dicha idea, tenemos una librería dinámica la cual existe para otorgar funciones a las aplicaciones, sin embargo dicha librería puede (por ejemplo) acceder a un recurso que no debe ser accedido a la vez por otro, sin embargo la librería es cargada en esos momentos por otra aplicacion la cual tambien carga dicha librería y (obviamente), intenta bloquear el recurso.

El anterior caso muestra la ineficiencia del CriticalSection entre varios procesos o DLLs.

Finalmente (y puesto me emocioné con el tema), hay otras consecuencias de que dicho objeto sea o no "propiedad" del kernel, como la velocidad de acceso entre uno y otro (el Mutex es más lento).

Sincronización.

Saludos

rolandoj · #3 13-03-2008

Hola,

Muchas gracias por la explicación.

Si entiendo bien el argumento, en mis palabra la situación sería la siguiente:

Escenario 1:

Cuando un DLL con variables globales se carga en memoria, por parte de una aplicación, se crea con su propia memoria compartida, y esta pertenece al hilo principal. Si la aplicación que la invocó no la descarga de memoria, cuando esa misma aplicación vuelve a llamar una función de esta librería, las variables globales siguen estando disponibles ya que la memoria en que están es apropiada por la instancia de esa aplicación.

Escenario 2

Si otra aplicación, o incluso la misma, llama a la librería cuando aún está bajo el control de la primera instancia, se crea un nuevo bloque de memoria para el hilo principal de una segunda donde residirá un nuevo juego de variables globales pertenecientes a la instancia que está siendo creada. Eso significa que ambas instancias tienen juegos de memoria diferentes; por tanto si hay un recurso compartido que debiera ser único a todo el sistema y se intenta controlarlo mediante una variable global definida dentro la librería, hay un problema porque no habría una variable "global", sino dos, una en cada instancia.

En términos prácticos, el control de los dos escenarios sería así:

Si en un DLL necesito proteger datos que son globales únicamente respecto a la instancia de mi programa, puedo usar TCriticalSection , y de hecho, debería, ya que es más rápido. Es decir, en el "Escenario 1", debo usar TCriticalSection

Por otra parte, si la sección de código que necesito proteger implica acceder a recursos que están fuera de la memoria de la instancia de mi programa, entonces no puedo usar TCriticalSection, sino que debo usar Mutex. En pocas palabras, el "Escenario 2"

La lógica planteada aplica tanto a variables en memoria que sean globales al sistema operativo, como a recursos en disco, u otros dispositivos físicos compartidos entre instancias. Sin embargo, hay una serie de recursos para los que el sistema operativo, o sus propios drivers, se ocupan de estos problemas. Por ejemplo, el caso de la impresión

En consecuencia, la pregunta interesante es : Cuales recursos, específicamente, deben ser protegidos así ?

En mi caso particular, lo que más me interesa en este momento es el manejo en Web Server Applications. Según entiendo, los servidores como IIS, Apache, etc, crean una sola instancia del DLL ISAPI respectivo, y los requerimiento que reciben se los pasan a dicha instancia que es la que crea diferentes hilos. Si estoy en lo correcto, dado que no tengo ningún otro mecanismo que invoque al DLL, las porciones compartidas, que no involucren nada externo, pueden manejarse vía Secciones Criticas. Podrías confirmarlo ?