Добрый день!

Не подскажите с реализациями завершения потоков? Как обработать такую ситуацию : дочерний поток висит на вызове блокируемой функции из third-party библиотеки. Родительский поток хочет его завершить. Как сделать? Учитывать корректное освобождение ресурсов.

Api: pthread, система: Linux

Спасибо!

Нет, я все-таки подскажу!!!
Чтобы разбудить блокированный поток, пошлите ему сигнал SIGTHR: pthread_kill(thr, SIGTHR).

Ой, простите. SIGTHR есть только в BSD. Похоже, в linux Вам поможет только pthread_cancel().

Сообщение отредактировал alx2 - Jun 18 2013, 04:14

pthread_cancel() доходит до потока когда он натыкается на cancellation point и поток завершается после этой точки, можно добавить обработчики на выходе. Но если используется сторонняя библиотека и один из ее вызовов прервется на середине выполнения при cancel(), откуда знать что она не рухнет, когда в обработчике будет происходит освобождение ее ресурсов. Тоже самое с сигналом и его обработчиком. Или хорошая библиотека не должна так делать?)
В функциях может стоять if (errno == EINTR)

Сообщение отредактировал Kirill_Good - Jun 18 2013, 06:23

Ниоткуда. Поток будет немедленно снят с выполнения, никакой код после заблокировавшего вызова не будет выполнен, и занятые ресурсы останутся занятыми.

Если бы у Вас библиотека была в исходниках, я бы предложил использовать в ней poll/select. Но у Вас, как я понял, исходников нет. Не знаю, как в linux решить эту проблему.

Вы можете просто убить поток, а освободить ресурсы в том месте где убили, но для этого надо иметь явный контекст потока

а не будет ли это одно и тоже, что и освободить ресурсы в обработчиках при завершении? Явный контекст потока , вы имели ввиду, что ясно представлять код?

Вроде как напрашивается только одно решение: делать код потока неблокируемым.

будет всё левак. самое грамотное - в сторонней библиотеке должна быть функция старта-останова стороннего потока. всё остальное - хождение по тонкому льду. шаг влево или вправо (не обязательно вы и не обязательно в ближайшем будущем) и кирдык всей конструкции.

а есть пример какой-нибудь?

пример чего? вызов функции или параметров возвращаемых? Или потроха самой функции?

сами функции чего-то аля (без привязки к юниксу или языку).



внутри - уже в зависимости от внутренней структуры библиотеки идёт запуск параллельных ниток либо их останов, в зависимости от логики. Если старт - захват ресурсов(если нужен), старт ниток, ожидание успешного старта ниток(в нитках может быть свой завхват ресурсов, который в зависимости от ОС может _не_ наследовать ресурсы парента), выход с кодом возврата. Если останов - сигнализация ниткам об их остановке. Ожидание пока нитки остановятся (выйдут из цикла, освободят ресурсы, если занимали), освобождение общих ресурсов (если таковые захватывались), выход с кодом возврата.

где то так.
особо отмечу _синхронную_фазу_старта_и_останова_ ниток. Типичная ошибка многих программистов не дожидаться подъёма и готовности ниток. Отсюда, при высокой нагрузке (ударной) по системе - идёт дрейф привычных временных интервалов. Или по другому. Если не ожидается успешность старта и начала работы нитки - то нафига её вообще порождать?

Вы наверно невнимательно прочитали тему. Вы дали "пример" функций о реализации которых тема и заводилась. Как вы сами описали, что эти функции часть api библиотеки. Где же место пользовательскому коду здесь?) Согласен с ситауцией допустим воспроизведение видео файла lib::start("file_path"); lib::stop(); Но такой простой api почти всегда не прокатывает. Такие функции носят больше reference характер, чем использование в рабочем коде. Также не все библиотеки имеют такой реферс. Всегда приходится реализовывать их самому. Вот об этом и вопрос. О конктретной части правда, как в функции stop() реализовать корректый останов потока?

Вы не вчитывались в мой первый ответ.

"будет всё левак. самое грамотное - в сторонней библиотеке должна быть функция старта-останова стороннего потока. всё остальное - хождение по тонкому льду. шаг влево или вправо (не обязательно вы и не обязательно в ближайшем будущем) и кирдык всей конструкции."

т.е. делать останов _не_ своей ветки = есть зло. Так понятней? Вы не можете гарантировать, не зная внутреннего устройства ветки, что она тормознётся _корректно_ !!! Т.е. если вы затачиваетесь на внутреннюю логику поведения библиотеки при том или ином Вашем внешнем воздействии - то это чревато в будущем(как минимум). Т.е. при незначительном изменении кода самой библиотеки, Вы рискуете опять начать всё сначала (разведку, перепрограммирования своего кода вызова-останова, тестирование).


если идёт речь о не понимании как это сделать _внутри_ библиотеки - то это попытка второго моего ответа. Т.е. внутри библиотеки, должно быть обеспечено на фазе старта:
1) вход
2) захват общих ресурсов, если есть. подготовка к старту нитки.
3) подъём нитки.
4) ожидание до окончания синхронной фазы подъёма (!!! эту фазу многие пропускают. чревато проблемами при ударных нагрузках на систему в целом).
5) обработка ошибок
6) выход.

При этом внутри подымаемой нитки код будет приблизительно следующий
1) вход
2) захват локальных (ведомых данной ниткой) ресурсов
3) обработка ошибок
4) сигнализация паренту о готовности к работе, либо ошибке.
5) уход на ожидание события либо саму работу.
---
6) бла-бла-бла (работа типа)
----
7) ожидание начала останова нитки из вне.
8) освобождение своих локально захваченных ресурсов.
9) обработка ошибок
10) сигнализация об успешном окончании нитки, либо ошибке
11) выход.

с 1 по 5 пункты зеркальны к пунктам с 7 по 11. Т.е. если Вы в нитке частично завхатили ресурсы, то и на выходе Вы должны освободить только захваченные ресурсы.

код останова будет выглядеть приблизительно следующим.
1) вход
2) выставили сигнальчик нитке об останове.
3) ожидание останова нитки.
4) освобождение общих ресурсов, если есть
5) обработка ошибок
6) выход


Для обеспечения постоянного мониторинга связи парент-чайлд применяют не блокирующие функции ввода-вывода. Обычно у чайлда всю работу делают квантованной и обрабатывают порциями. При этом обычно выделяется основной цикл, внутри которого обрабатывают в том числе и сигналы приходящие от парента.

Сообщение отредактировал kolobok0 - Jul 8 2013, 10:46

Давайте я расскажу ход моих мыслей, когда я читал ваши ответы.



Здесь вы сказали, что код дочернего потока делать не блокируемым это не вариант. Дальше вы пишите.


С этим я соглашусь. Эту мысль я отразил в своей фразе ...Вроде как напрашивается только одно решение

Затем.



То есть вы предложили вариант, который отвергли в предыдущем сообщении.

Так же я писал.

Вот об этом и вопрос. О конктретной части правда, как в функции stop() реализовать корректый останов потока?

Вы написали кусок текста про работу с потоками, который не содержал ответа на вопрос.

Тут либо я тугой, либо кто то другой. Если я, то признаю , если будут аргументы.

В дочернем потоке вызвать
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
перед вызовом блокируемой функции.
Тогда дочерний поток может быть завершен с помощью pthread_cancel в любой момент, в т.ч. когда висит на вызове блокируемой функции.

а где освобождить ресуры?

Зависит от конкретной реализации. Наверное, там же, где вызывается pthread_cancel.