Первое, что я бы попробовал, это пнуть условную переменную между отменой и соединением, и заставить целевой поток явно проверять отмену после того, как он вернется из условия ожидания.
Это потому, что оновозможно, что поток не отвечает на отмену, пока он находится в состоянии ожидания (или вообще не работает).
POSIX.1c-2004 (v6) сообщает:
Состояние отменыи тип всех вновь создаваемых потоков, включая поток, в котором main () был впервые вызван, должен быть PTHREAD_CANCEL_ENABLE
и PTHREAD_CANCEL_DEFERRED
соответственно.
Это означает, что вы должны явно проверить на отмену сpthread_testcancel()
.
Другой вариант заключается в том, чтобы фактически установить тип отмены потоков на PTHREAD_CANCEL_ASYNCHRONOUS
при первом запуске, например:
int junk;
pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, &junk);
std::cout
<< ((junk==PTHREAD_CANCEL_DEFERRED) ? "Was deferred" : "Wasn't")
<< std::endl;
То есть, конечно,при условии, что это проблема.Вы должны быть в состоянии проверить, проверяет ли он вывод этой третьей строки выше.
Отмена - это запрос к целевому потоку, который он может игнорировать, если пожелает, так какпротив гораздо большего зла pthread_kill()
.Я большой сторонник того, чтобы позволить потокам контролировать их собственные жизни, поскольку я обнаружил, что это неизменно приводит к меньшему количеству проблем параллелизма.
В стороне: Фактически, будучи скупленнымв очень ранних выпусках pthreads, даже до интеграции в DCE, я все еще обнаружил, что просто использую глобальную переменную для каждого потока, указывающую, когда он должен завершиться, наряду с ручными ударами мьютексов или условных переменных, чтобы разбудить потоки,Я думаю, что я должен обновить свои методы (или я хотел бы, если бы я мог видеть явное преимущество).: -)