suspend/resume thread в linux, как реализовать?

Через что потоки реализованы? Процессам можно просто слать сигналы STOP и CONT через банальный kill.

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

Пора мне выползать из криокамеры, со времен linux 2.4 слишком многое поменялось :)

Condition variables?

Потоки реализуются через PTHREAD.

Какие проблемы могут возникнуть во всем приложении при использовании сигналов STOP/CONT относительно какого либо потока(процесса)?

Какие еще есть способы решения данной задачи?

QThread::sleep

sleep не подходит по двум причинам: поток в «спячке» может находится как больше указанного в sleep времени(завершится прежде временно), так и меньше указанного в sleep времени, тут надо будет вмешивается в рабочий поток, что не очень хорошо.

Нормально - никак (да это и не нужно). Через жо^Wсигналы, наверное, можно, но зачем?

Используй блокирующие чтение/запись (сокеты, pipe и прочее зло). Тогда

Поток A в произвольный момент времени «усыпляем» из самого потока A

т.е. A повисает на чтении из трубы

через n-ый промежуток времени ... из потока B «пробуждаем» поток A

т.е. пишем в трубу из B

На блокирующем чтении поток _действительно_ засыпает.

>Какие проблемы могут возникнуть во всем приложении при использовании сигналов STOP/CONT относительно какого либо потока(процесса)?

этими сигналами ты заморозишь весь процесс целиком, со всеми потоками. Чем тебя sigwait не устраивает?

Суть в том, что «усыпление» и «пробуждение» уже существующего потока гораздо быстрее, чем создание нового потока. То есть выходит следующий тип приложения: запущено фиксированное количество потоков, и каждый поток в случае наличия работы, выполняет ее, а в случае отсутствия работы находится в спящем состоянии. Похоже на демона который слушает какой либо сокет, но в данном случае поток просто находится в спящем состоянии и по команде выполняет те или иные вычисления.

man sem_wait
man sem_post

man pthread_cond_wait
man pthread_cond_signal

>этими сигналами ты заморозишь весь процесс целиком, со всеми потоками. Чем тебя sigwait не устраивает?

Пока не знаю, из всех возможных вариантов выберу один, который для меня будет самым оптимальным

>Используй блокирующие чтение/запись (сокеты, pipe и прочее зло). Тогда

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

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

Ну как знаешь

man eventfd

Я немного позже напишу код, может тогда, что я хочу, станет более понятно.

А у тебя вариантов других и нету. Тебе нужен какой-нибудь блокирующий примитив. Тебе уже четыре предложили fifo, eventfd, posix ipc sems, condition vars. Я бы выбрал последний ибо из ptheads. Если будешь своё поделие обратно потрировать - для винды эта либа есть, будет совместимо на уровне исходников.

Да и вообще, усыплять потоки в любом месте его исполнение - хреновая идея by design. Должны быть некие опорные точки, в которых он может заснуть (а может и нет). Представь что ты тред саспендишь во время выполнения timeofdate например. В ядре ответ уже готов и осталось только зделать return и тут раз, и саспенд реквест. Как быть?

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

Сигналы потоку послать нельзя, их процессу посылают. А какой поток их будет обрабатывать зависит от маски. По умолчанию - любой. Вот такой вот недостаток. Короче - сигналы придумали когда потоков ещё не было, а когда потоки делали, ввели такое понятие как маска. Читай те самые страницы в общем, там написано доходчивее.

>Сигналы потоку послать нельзя, их процессу посылают

Можно. Только лучше этим вообще не пользоваться.

Не уверен, что понимаю вас, но может вы обратите свой взор на функции pthread_cond_wait() и pthread_cond_signal() или pthread_cond_broadcast()? Плюс, может вам стоит задуматься о создании управляющего потока?

Сигналы получают все потоки. Никак изменить это нельзя. Можно пытаться строить всякие логические фильтры для обработки сигналов, но это страшные костыли.

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

Что-то у меня складывается впечатление, что тебе нужно совсем не то, о чем ты спросил.

>Сигналы получают все потоки.

Как уже было сказано раньше, pthread_kill.

>... pthread_sigmask, pthread_kill и sigwait ...

Написал код с помощью вышеперечисленных функций, вышло вроде то что надо, вообщем оформлю код и выложу в этом посте может кому то еще пригодится.

Всем спасибо за идеи!