Seguridad en hilos

No es fácil determinar si una pieza de código es segura en cuanto a los hilos o no. Sin embargo, hay varios indicadores que sugieren la necesidad de un examen cuidadoso para determinar si es inseguro:

• acceder a las variables globales o al heap
• asignar/liberar recursos que tienen límites globales (ficheros, procesos y subprocesos, etc.)
• accesos indirectos a través de handle o punteros
• cualquier efecto co-lateral visible (por ejemplo, acceso a variables volátiles en el lenguaje de programación C)

Una subrutina tiene seguridad en hilos, y por tanto es reentrante, si solo usa variables de la pila, depende solo de los argumentos que le pasen, y solo llama a otras subrutinas con propiedades similares. A esto a veces se le llama "función pura" y se parece mucho a una función matemática. No todas las funciones reentrantes son thread-safe.

Hay unas pocas maneras de conseguir esta seguridad:

• Código reentrante: Básicamente, escribir código de tal manera que pueda ser interrumpido durante una tarea, ser ejecutado (reentrado) de nuevo para realizar otra tarea, y después continuar con su tarea original. Esto normalmente incluye guardar la información de estado en variables locales, en lugar de usar variables estáticas o variables globales.
• Exclusión mutua: El acceso a los datos compartidos es serializado usando mecanismos que aseguran que solo un thread está accediendo a los datos compartidos al mismo tiempo. Se requiere gran cautela si una pieza de código accede a múltiples piezas compartidas de datos - los problemas incluyen condición de carrera, deadlocks, livelocks, inanición de recursos (starvation), y otros males enumerados en los libros de texto de los sistemas operativos.
• Almacenamiento thread-local: Variables están localizadas de manera que cada thread tiene su propia copia privada. Las variables retienen sus valores a través de la subrutina y otros límites de código, y el código al cual acceden podría no ser reentrante, pero dado que son locales a cada hilo, son thread-safe.
• Operación atómica: Los datos compartidos son accedidos usando Atomicidad la cual no puede ser interrumpida por otros threads. Esto normalmente necesita usar instrucciones especiales del lenguaje máquina, las cuales podrían estar disponibles en una biblioteca de runtime. Dado que las operaciones son atómicas, los datos compartidos están siempre guardados en un estado válido, sin importar el orden en que los threads acceden. Atomicidad forma la base de muchos mecanismos de bloqueo de thread.

Un idioma de uso general combina estos acercamientos:

• hacer cambios a una copia privada de los datos compartidos y entonces actualizad atómicamente los datos compartidos desde la copia privada. Así, la mayoría del código es concurrente, y se pierde poco tiempo en la serialización.

• Control de concurrencia
• Manejo de excepciones

• Short description of thread-safe
• Writing Reentrant and Thread-Safe Code
• Thread-safe Tcl Extensions (wiki page)
• Thread-safe design Archivado el 9 de julio de 2006 en Wayback Machine.
• Article "Write thread-safe servlets Archivado el 10 de agosto de 2006 en Wayback Machine." by Phillip Bridgham
• Article "Smart Pointer Thread Safety" by Dejan Jelovic
• A Short Guide to Mastering Thread-Safety