Buenas noches,
Me encontraba leyendo el código proporcionado para la segunda parte del obligatorio 2, y creo haber encontrado problemas con el manejo de threads. A continuación un par de ejemplos:
1. En sr_handle_pwospf_packet, esta línea
pthread_create(&g_rx_lsu_thread, NULL, sr_handle_pwospf_lsu_packet, rx_lsu_param);
pretende procesar un mensaje LSU en un nuevo hilo. El problema está en que siempre utiliza la variable global g_rx_lsu_thread para almacenar el thread ID del proceso. Según las man-pages de pthread, hacer esto si el ID está siendo ocupado causará undefined behaviour. Además, eso ―a mi entender― siempre sucederá: la invocación a pthread_create no recibe ningún argumento attr, causando que el hilo sea joinable por defecto, en lugar de detached. Por ende, sus recursos no serán liberados por completo hasta que otro hilo le haga join, cosa que no sucede.
2. En run_dijkstra, tenemos lo siguiente
void* run_dijkstra(void* arg)
{
dijkstra_param_t* dij_param = ((dijkstra_param_t*)(arg));
pthread_mutex_t dijkstra_mutex = PTHREAD_MUTEX_INITIALIZER;
struct pwospf_topology_entry* topology = dij_param->topology;
struct in_addr router_id = dij_param->rid;
pthread_mutex_lock(&dijkstra_mutex);
...
Por lo visto, pareciera que se pretende mutuo-excluir la ejecución de diferentes ejecuciones de la función, imagino que para evitar race-conditions en la manipulación de la topología. El problema es que se utiliza un mutex que está siendo localmente definido e inicializado. Es decir ―si no me equivoco―, que cada invocación será indiferente a las demás, ya que estará chequeando un mutex que solo ella conoce (porque lo acaba de crear ahí mismo), en lugar de potencialmente esperar por la liberación de un mutex global a todas las ejecuciones de run_dijkstra.
¿Qué opinan?
Saludos,
-Jero