Tengo entendido que algunas, si no todas, las llamadas al sistema pueden estar bloqueadas. ¿Es esta una llamada de bloqueo? Quiero obtener una identificación de hilo única en una función que se llama repetidamente y es sensible al tiempo. Iba a hacer así:
//header.h #define _GNU_SOURCE #include <sys/syscall.h> #ifdef SYS_gettid #define gettid() syscall(SYS_gettid) #else #define gettid() 0 #endif //file.c #include "header.h" ... void function() { pid_t thread = gettid(); //Logic based on thread ... } Aquí la función se llamará repetidamente y no se puede bloquear. ¿Quizás debería usar pthread_self() y pthread_equal(t1, t2) ? Gracias.
EDITAR: Podría usar cualquiera de los dos igualmente. Entiendo que no proporcionan los mismos valores de retorno, pero la lógica que aplicaré en la identificación del subproceso es compararla con un conjunto de identificaciones de subprocesos conocidas para averiguar básicamente quién está llamando. Tengo tanto el valor de retorno de gettid() como el valor de retorno de pthread_self() guardados.
Debe usar pthread_self , principalmente porque es portátil y syscall(SYS_gettid) no lo es, pero también porque las implementaciones típicas no necesitan atrapar el kernel en absoluto. Por ejemplo, en la máquina donde estoy escribiendo esto, hay un registro de hardware especial llamado tpidr_el0 que almacena un puntero a datos específicos del subproceso, por lo que pthread_self puede ser solo tres instrucciones, sin necesidad de cambiar el nivel de privilegio:
0000000000077870 <pthread_self>: 77870: d53bd040 mrs x0, tpidr_el0 77874: d11e4000 sub x0, x0, #0x790 77878: d65f03c0 retPara ser justos, una llamada al sistema en esta arquitectura también es solo un puñado de instrucciones, por ejemplo
00000000000a67c0 <getpid>: a67c0: d503245f bti c a67c4: d2801588 mov x8, #0xac a67c8: d4000001 svc #0x0 a67cc: d65f03c0 ret pero un volcado de ensamblaje del stub syscall no muestra los cientos o incluso miles de ciclos de costos que se esconden detrás de esa instrucción svc . Si está haciendo algo frecuente y sensible al tiempo, no atrapar el kernel puede ser una gran victoria.
También te recomiendo que pienses en reorganizar tu código para que el trabajo llegue en lotes más grandes y no necesites preguntar "¿en qué hilo estoy?" tan a menudo. Las operaciones que no se realizan en absoluto son siempre las más rápidas.