pthread_kill(tid, 0);

Сигнал не отправляется, но проверка ошибок по-прежнему выполняется, поэтому вы можете использовать это для проверки существования tid.

ВНИМАНИЕ: этот ответ неверен. В стандарте конкретно запрещается передавать идентификатор потока, срок службы которого закончился. Этот идентификатор теперь может указывать другой поток или, что еще хуже, он может ссылаться на освобожденную память, вызывая сбой.

Не существует полностью портативного решения, посмотрите, поддерживает ли ваша платформа pthread_tryjoin_np или pthread_timedjoin_np. Поэтому вы просто проверяете, может ли поток быть присоединен (конечно, созданный с помощью PTHREAD_CREATE_JOINABLE).

Я думаю, что вам действительно нужно называть pthread_join (). Этот вызов не будет возвращен до тех пор, пока поток не выйдет.

Если вы хотите только опросить, будет ли поток работать или нет (и обратите внимание, что обычно это не то, что вам нужно делать! ), у вас может быть поток, задающий volatile boolean на false, прежде чем он выйдет ... тогда ваш основной поток мог бы прочитать логическое значение, и если это все еще верно, вы знаете, что поток все еще работает. (если это ложь, с другой стороны, вы знаете, что поток, по крайней мере, почти ушел, он все равно может запускать код очистки, который возникает после того, как он устанавливает логическое значение в false, хотя, тем не менее, даже в этом случае вам все равно следует вызвать pthread_join before пытаясь освободить любые ресурсы, к которым у потока может быть доступ)

Позвольте мне отметить «выигрышный» ответ, который имеет огромный скрытый недостаток, и в некоторых контекстах это может привести к сбоям. Если вы не используете pthread_join, он будет появляться снова и снова. Предположим, что у вас есть процесс и общая библиотека. Вызовите библиотеку lib.so.

1. Вы закрываете ее, вы начинаете в ней нить. Предположим, вы не хотите, чтобы он присоединился к нему, поэтому вы установите его съемным.
2. Логика процесса и общей библиотеки lib и т. Д. ...
3. Вы хотите загрузить lib .so, потому что вам это больше не нужно.
4. Вы вызываете выключение по потоку, и вы говорите, что вы хотите прочитать флаг после этого из потока lib.so, который он закончил .
5. Вы продолжаете в другом потоке с dlclose, потому что видите, что вы видели, что флаг теперь показывает поток как «законченный»
6. dlclose будет загружать весь стек и память, связанная с кодом.
7. Whops, но dlclose не останавливает потоки. И вы знаете, даже когда вы находитесь в последней строке обработчика очистки, чтобы установить «поток завершен» изменчивой переменной атомного флага, вам все равно придется возвращаться из множества методов в стеке, возвращая значения и т. Д. Если приоритет огромного потока был задан нитью # 5 + # 6, вы получите dlclose, прежде чем сможете ДЕЙСТВИТЕЛЬНО остановить поток. Иногда у вас будут какие-то приятные сбои.

Позвольте мне отметить, что это не проблема с hipothetical, у меня была такая же проблема в нашем проекте.

#include <string.h>
#include <stdio.h>
#include <pthread.h>
#include <signal.h>
#include <unistd.h>

void* thread1 (void* arg);
void* thread2 (void* arg);

int main()
{
    pthread_t thr_id;

    pthread_create(&thr_id, NULL, thread1, NULL);

    sleep(10);
}

void* thread1 (void* arg)
{
    pthread_t thr_id = 0;

    pthread_create(&thr_id, NULL, thread2, NULL);

    sleep(5);
    int ret = 0;
    if( (ret = pthread_kill(thr_id, 0)) == 0)
    {
        printf("still running\n");
        pthread_join(thr_id, NULL);
    }
    else
    {
        printf("RIP Thread = %d\n",ret);
    }
}

void* thread2 (void* arg)
{
//  sleep(5);
    printf("I am done\n");
}