Корректное завершение потока (pthread, Linux) Опции

[Kirill_Good]

Добрый день!

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

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

Спасибо!

[alx.bilous]

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

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

[Kirill_Good]

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

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

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

[kolobok0]

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

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

[Kirill_Good]

в сторонней библиотеке должна быть функция старта-останова стороннего потока.

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

[kolobok0]

.. пример..

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

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

Код

HANDLE Start();

error Stop(HANDLE);

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

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

[Kirill_Good]

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

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

Код

HANDLE Start();

error Stop(HANDLE);

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

[kolobok0]

... Где же место пользовательскому коду здесь?)...

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

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

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


если идёт речь о не понимании как это сделать _внутри_ библиотеки - то это попытка второго моего ответа. Т.е. внутри библиотеки, должно быть обеспечено на фазе старта:
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

[Kirill_Good]

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

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

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

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

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

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

Затем.

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

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

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

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

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

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

[kolobok0]

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

простите, только сейчас зашёл снова сюда...

моя фраза:

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

эээээээээээээээ, простите где здесь "код дочернего потока делать не блокируемым это не вариант" ???

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

так, что ваша фраза "код дочернего потока делать не блокируемым это не вариант" не понятна в принципе. такое ощущение, что Вы не поняли написанное мною(либо не захотели понять - хз).

дальше...

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

простите но в

"Для обеспечения постоянного мониторинга связи парент-чайлд....(и далее)"

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

"т.е. делать останов _не_ своей ветки = есть зло......(и далее)"

говорилось совсем о другом. что не стоит прерывать работу чайлдовой нитки _не_официально_ для неё. Т.е. не сигнализируя ей об останове терминировать её, либо выдать через переферию которая она юзает не ликвидное значение и т.п. вещи.

эти два сообщения вообще то о разном были... как не надо и как возможно - на примере.

ясность появилась на горизонте или туман сгущается?

Сообщение отредактировал kolobok0 - Aug 2 2013, 15:44