Programación en C: Depuración con pthreads

Una de las cosas que le sorprenderá acerca de depurar programas enhebrados es que a menudo encontrará que el error cambia, o incluso desaparece cuando agrega printf o ejecuta el programa en el depurador (coloquialmente conocido como Heisenbug).

En un programa enhebrado, un Heisenbug generalmente significa que tienes una condición de carrera . Un buen programador buscará variables o recursos compartidos que dependan del orden. Un programador de mierda tratará de arreglarlo ciegamente con el sueño() instrucción.

Depurar una aplicación multiproceso es difícil. Un buen depurador como GDB (con front end opcional DDD) para el entorno *nix o el que viene con Visual Studio en Windows ayudará enormemente.

En la fase de 'pensar', antes de empezar a codificar, utilice el concepto de Máquina de Estados. Puede hacer el diseño mucho más claro.

Printf puede ayudarle a entender la dinámica de su programa. Pero desordenan el código fuente, así que usa una macro DEBUG_OUT () y en su definición habilítala con una bandera booleana. Mejor aún, establezca / borre esta bandera con una señal que envíe a través de 'kill-USR1'. Envíe la salida a un archivo de registro con una marca de tiempo.

También considere usar assert (), y luego analice sus volcados de núcleo usando gdb y ddd.

Mi enfoque para la depuración multihilo es similar al subproceso simple, pero generalmente se pasa más tiempo en la fase de pensamiento:

1. Desarrollar una teoría sobre lo que podría estar causando el problema.

2. Determinar qué tipo de resultados podrían esperarse si la teoría es cierta.

3. Si es necesario, agregue código que pueda refutar o verificar sus resultados y teoría.

4. Si tu teoría es cierta, arregla el problema.

A menudo, el 'experimento' que prueba la teoría es la adición de una sección crítica o mutex alrededor del código sospechoso. Entonces trataré de reducir el problema reduciendo sistemáticamente la sección crítica. Las secciones críticas no siempre son la mejor solución (aunque a menudo puede ser la solución rápida). Sin embargo, son útiles para identificar la 'pistola humeante'.

Como dije, los mismos pasos se aplican a la depuración de un solo subproceso, aunque es demasiado fácil saltar a un depurador y hacerlo. La depuración multihilo requiere una comprensión mucho más fuerte del código, ya que generalmente encuentro que el código multihilo en ejecución a través de un depurador no produce nada útil.

Además, hellgrind es una gran herramienta. El comprobador de subprocesos de Intel realiza una función similar para Windows, pero cuesta mucho más que hellgrind.

Me desarrollo en un mundo exclusivamente multihilo y de alto rendimiento, así que aquí está la práctica general que uso.

Diseño - la mejor optimización es un algoritmo mejor:

1) Divide tus funciones en piezas LÓGICAMENTE separables. Esto significa que una llamada hace "A" y SOLO " A " - no A entonces B entonces C...
2) NO HAY EFECTOS SECUNDARIOS: Abolir todas las variables abiertamente globales, estáticas o no. Si no puede eliminar completamente los efectos secundarios, aíslelos en algunos lugares (concéntrelos en el código).
3) Hacer tantos componentes aislados REENTRANTE como sea posible. Esto significa que son apátridas-toman todas sus entradas como constantes y solo manipulan los parámetros declarados, lógicamente constantes para producir la salida. Pase-por-valor en lugar de referencia siempre que pueda.
4) Si tiene estado, haga una separación clara entre los subconjuntos sin estado y la máquina de estado real. Idealmente, la máquina de estados será una sola función o clase manipulando componentes sin estado.

Depuración:

Los errores de enhebrado tienden a venir en 2 sabores amplios: razas y bloqueos. Como regla general, los puntos muertos son mucho más deterministas.

1) ¿Ves corrupción de datos?: YES = > Probably a race.
2) ¿Surge el error en CADA carrera o solo en algunas carreras?: YES = > Likely a deadlock (races are generally non-deterministic).
3) ¿El proceso se cuelga alguna vez?: YES => There's a deadlock somewhere. Si solo se cuelga a veces, es probable que tenga una carrera demasiado.

Los puntos de interrupción a menudo actúan como primitivas de sincronización en el código, porque son lógicamente similares: obligan a la ejecución a detenerse en el contexto actual hasta que otro contexto (usted) envíe una señal para reanudar. Esto significa que debe ver cualquier punto de interrupción que tenga en el código como alterar su comportamiento de subprocesos mufti, y los puntos de interrupción afectarán las condiciones de carrera, pero (en general)no los bloqueos.

Como regla general, esto significa que debe eliminar todos los puntos de interrupción, identificar el tipo de error, LUEGO reintroducirlos a intentar solucionarlo. De lo contrario, simplemente distorsionan las cosas aún más.

Tiendo a usar muchos puntos de interrupción. Si en realidad no se preocupan por la función de hilo, pero se preocupan por sus efectos secundarios, un buen momento para comprobarlos podría ser justo antes de que salga o vuelva a su estado de espera o cualquier otra cosa que esté haciendo.

Cuando empecé a hacer programación multiproceso I... dejó de usar depuradores. Para mí, el punto clave es una buena descomposición y encapsulación del programa.

Los monitores son la forma más fácil de programar multihilo sin errores. Si no puede evitar dependencias de bloqueo complejas, entonces es fácil comprobar si son cíclicas - espere hasta que el programa se cuelgue y compruebe los stacktraces usando 'pstack'. Puede romper los bloqueos cíclicos introduciendo algunos hilos nuevos y comunicación asíncrona búfer.

Use aserciones, y asegúrese de escribir unittests singlethreaded para componentes particulares de su software; luego puede ejecutarlos en debugger si lo desea.