-
Crea un hilo separado cuando sepas que no querrás esperar con
pthread_join(). El único beneficio de rendimiento es que cuando finaliza un subproceso desconectado, sus recursos se pueden liberar de inmediato en lugar de tener que esperar a que se una el subproceso antes de poder liberar los recursos. -
Es 'legal' no unirse a un hilo que se puede unir; pero no suele ser aconsejable porque (como se indicó anteriormente) los recursos no se liberarán hasta que se una el subproceso, por lo que permanecerán atados indefinidamente (hasta que el programa salga) si no se une.
¿Cuándo debo crear un hilo como separado, desde el principio?
Siempre que a la aplicación no le importe cuándo se completa ese hilo y tampoco le importa el valor de retorno de un hilo (un hilo puede comunicar un valor a otro hilo/aplicación a través de pthread_exit ).
Por ejemplo, en un modelo de aplicación cliente-servidor, un servidor puede crear un nuevo subproceso para procesar cada solicitud. Pero al servidor en sí no le importa el valor de retorno del hilo. En ese caso, tiene sentido crear separado hilos.
Lo único que el servidor debe asegurarse es que las solicitudes procesadas actualmente se completen. Lo que puede hacer, simplemente saliendo del hilo principal sin salir de todo el programa/aplicación. Cuando finaliza el último subproceso del proceso, la aplicación/programa se cerrará de forma natural.
El pseudocódigo podría verse así:
/* A server application */
void process(void *arg)
{
/* Detach self. */
pthread_detach(pthread_self());
/* process a client request. */
pthread_exit(NULL);
}
int main(void)
{
while (not_done) {
pthread_t t_id;
errno = pthread_create(&t_id, NULL, process, NULL);
if (errno) perror("pthread_create:");
}
/* There may be pending requests at this point. */
/* Just exit the main thread - not the whole program - so that remaining
requests that may still be processed can continue. */
pthread_exit(NULL);
}
Otro ejemplo podría ser un subproceso de registro o daemon que registra cierta información a intervalos regulares mientras se ejecuta la aplicación.
¿Ofrece alguna ventaja de rendimiento en comparación con un subproceso que se puede unir?
En cuanto al rendimiento, no hay diferencia entre unible hilos vs separados hilos. La única diferencia es que con subprocesos separados, sus recursos (como la pila de subprocesos y cualquier memoria de montón asociada, etc., exactamente lo que constituye esos "recursos" son específicos de la implementación).
¿Es legal no hacer un pthread_join() en un subproceso que se puede unir (por defecto)?
Sí, es legal no unirse a un hilo. pthread_join es una función de conveniencia que de ninguna manera debe usarse a menos que lo necesite. Pero tenga en cuenta que los hilos creados son asociables hilos por defecto.
Un ejemplo en el que podría querer unirse es cuando los subprocesos realizan una "pieza" de trabajo que se divide entre ellos. En ese caso, querrá verificar que todos los subprocesos estén completos antes de continuar. El paralelismo de la granja de tareas es un buen ejemplo.
¿O tal hilo debería usar siempre la función detach() antes de pthread_exit()ing?
No es necesario. Pero a menudo querrás decidir si quieres un unible o separado hilo en el momento de la creación.
Tenga en cuenta que si bien se puede crear un hilo separable configurando el atributo PTHREAD_CREATE_DETACHED con una llamada a pthread_attr_setdetachstate , una decisión de subproceso puede decidir desconectarse en cualquier momento, p. con pthread_detach(pthread_self()) . Además, un hilo que tiene la identificación del hilo (pthread_t ) de otro hilo puede separarse con pthread_detach(thread_id); .