Se un processo è bloccato, l'auto monitoraggio per quel processo non sarebbe così produttivo. Tuttavia, se si desidera che tale processo accorga che non è stato eseguito per un po ', può chiamare periodicamente lo times e confrontare la differenza relativa nel tempo trascorso con la differenza relativa nell'ora dell'utente pianificata (sommando i campi tms_utime e tms_cutime se si desidera contare i tempi di attesa dei bambini come tempo produttivo e si sommano nei campi tms_stime e tms_cstime se si considera che il tempo di kernel speso per conto dell'utente è produttivo). Per i tempi di thread, l'unico modo che conosco è di consultare il filesystem /proc.
Un processo esterno ad alta priorità o un thread ad alta priorità può monitorare esternamente processi (e thread) di interesse leggendo le voci /proc/<pid>/stat appropriate per il processo (e /proc/<pid>/task/<tid>/stat per i thread). Gli orari utente si trovano nei campi 14 e 16 del file stat. I tempi di sistema si trovano nei campi 15 e 17. (Le posizioni dei campi sono accurate per il mio kernel Linux 2.6)
Tra due punti di tempo, si determina la quantità di tempo trascorso che è passato (un processo di monitoraggio o thread di solito si sveglia a intervalli regolari). Quindi la differenza tra i tempi di elaborazione cumulativi in ognuno di quei punti temporali rappresenta quanto tempo il thread di interesse ha avuto modo di eseguire durante quel periodo. Il rapporto tra il tempo di elaborazione e il tempo trascorso rappresenterebbe la porzione temporale.
Un'ultima po 'di info: Su Linux, io uso il seguente per ottenere il tid del thread corrente per l'esame del diritto task nella directory /proc/<pid>/task/:
tid = syscall(__NR_gettid);
faccio questo, perché non potevo trova la chiamata di sistema gettid effettivamente esportata da qualsiasi libreria sul mio sistema, anche se è stata documentata. Ma potrebbe essere disponibile sul tuo.