2009-04-11 12 views
11

Estoy escribiendo una aplicación de servidor en Delphi 2009 que implementa varios tipos de autenticación. Cada método de autenticación se almacena en un dll separado. La primera vez que se utiliza un método de autenticación, se carga el dll apropiado. El dll solo se lanza cuando la aplicación se cierra.¿Es seguro llamar a una función dll desde múltiples hilos en una sola aplicación?

¿Es seguro acceder a los dlls sin ninguna forma de sincronización entre los hilos del servidor (conexiones)?

Respuesta

17

Respuesta corta:

Sí, en general es posible llamar a una función DLL desde varios subprocesos, ya que cada hilo tiene su propia pila y llamar a una función DLL es más o menos lo mismo que llamar a cualquier otro función de tu propio código

Respuesta larga:

Si es realmente posible depende de las funciones DLL utilizando un compartían estado mutable o no.

Por ejemplo si haces algo como esto:

DLL_SetUser(UserName, Password) 
if DLL_IsAuthenticated then 
begin 
... 
end; 

entonces es sin duda no seguro para ser utilizado de diferentes temas. En este ejemplo, no puede garantizar que entre DLL_SetUser y DLL_IsAuthenticated ningún otro hilo haga una llamada diferente al DLL_SetUser.

Pero si las funciones DLL no dependen de algún tipo de estado predefinido, es decir, todos los parámetros necesarios están disponibles a la vez y todas las demás configuraciones son iguales para todos los subprocesos, puede suponer que funcionarán.

if DLL_IsAuthenticated(UserName, Password) then 
begin 
... 
end; 

Pero tenga cuidado: es posible que una función DLL parezca atómica, pero internamente usa algo, que no lo es. Si, por ejemplo, si el archivo DLL crea un archivo temporal con siempre el mismo nombre o si accede a una base de datos que solo puede gestionar una solicitud a la vez, cuenta como un estado compartido. (Lo siento, no podía pensar en mejores ejemplos)

Resumen:

Si dicen los vendedores DLL, que sus archivos DLL son hilos de proceso seguro que haría uso de ellos desde varios subprocesos sin bloquear. Si no lo están, o incluso si los proveedores no lo saben, debes ir a lo seguro y usar el bloqueo.

Al menos hasta que encuentre problemas de rendimiento. En ese caso, podría intentar crear múltiples aplicaciones/procesos que envuelvan sus llamadas a DLL y las usen como servidores proxy.

+1

Otro ejemplo podría ser una estructura de datos interna donde las funciones exportadas agregan y/o eliminan elementos, como una lista de solicitudes de autenticación (fallidas) o una lista de usuarios autenticados. – mghie

-1

Si habla de archivos DLL Win32, están destinados a ser seguros si son invocados por varios subprocesos, aplicaciones. No sé lo que hace su DLL, pero si su DLL está utilizando un recurso bloqueable como un archivo o un puerto, entonces podría haber problemas basados ​​en la implementación dentro de la DLL.

No estoy familiarizado con el funcionamiento de las DLL de autenticación de Delphi 2009. Tal vez debería agregar esa información al título (que está hablando específicamente de las DLL de Delphi 2009)

+0

Los archivos DLL Win32 son archivos DLL que se pueden cargar en Win32. ¿Quizás quiso decir "DLL de sistema de Windows" en su lugar? Además, Delphi 2009 no tiene nada como "DLL de autenticación". Deben ser DLL de terceros de algún tipo. –

4

Para que sus archivos DLL sean seguros para subprocesos, debe proteger todas las estructuras de datos compartidas a las que podrían acceder varios subprocesos en un proceso al mismo tiempo, no hay diferencia aquí entre escribir código para una DLL y escribir código para un ejecutable.

Para procesos múltiples no hay riesgo en el acceso concurrente, ya que cada proceso obtiene su propio segmento de datos para la DLL, por lo que las variables con el mismo nombre son realmente diferentes cuando se ven desde procesos diferentes. En realidad, es mucho más difícil proporcionar datos en una DLL que es la misma de diferentes procesos, básicamente necesitaría implementar las mismas cosas que usaría para el intercambio de datos entre procesos.

Tenga en cuenta que una DLL es especial en el sentido de que recibe notificaciones cuando un proceso o un hilo se conecta o desconecta de una DLL. Consulte la documentación del DllMain Callback Function para obtener una explicación, y this article para ver un ejemplo de cómo usar esto en una DLL escrita con Delphi. Entonces, si sus hilos no son completamente independientes unos de otros (y no se puede acceder a los datos compartidos), entonces necesitará algunas estructuras de datos compartidas con acceso sincronizado. Las diversas notificaciones pueden ayudarlo a configurar correctamente las estructuras de datos en su archivo DLL.

Si sus DLL permiten la ejecución completamente independiente de las funciones exportadas, también verifique threadvar variables específicas de subprocesos. Tenga en cuenta que para ellos inicialización y finalización secciones no son utilizables, pero tal vez las notificaciones de subprocesos también pueden ayudarlo.

0

Esto es lo que sucede: no se puede asumir que las DLL son seguras para hilos si no se tiene control sobre el código fuente (o sobre la documentación que lo indica), por lo que se supone que son las peores.

Cuestiones relacionadas