Подскажите, куда копать.

Есть ряд задач, выполняются они последовательно. В прицнипе, их можно выполнять и параллельно, но пока до этого не добрался.
Задача - это некая операция, которая повторяется последовательно с нуля до бесконечности раз. Несколько задач - запускается первая задача первый раз, потом вторая задача первый раз, ... потом снова первая задача второй раз и т.д.

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

Использование потоков - крайне затратная конструкция в данном случае.
Общее число задач, исполняемых друг за другом - от одного до двух десятков.
В среднем за секунду исполняется от 30к до 1м задач.

=//=

Dima TПул из N потоков создаешь при старте и дальше выполняй свои задачи в них.

Если задачи чисто вычислительные, то N равно количеству ядер проца, иначе N подбери опытным путем.

На каком ЯП написано? Нет смысла рассматривать эту задачу обобщенно, в разных ЯП разные инструменты для распараллеливания.Пул потоков не пойдет, потому что после полного цикла задач ABCDEF...Z перед повтором круга нужна полная синхронизация. А редко нужна и последовательная синхронизация, чтобы задачи A->B->C->... и только в таком порядке.

При скорости исполнения с 100к задач в секунду будет скажем 30к синхронизаций в секунду, пул потоков такое не вытянет.

С++, win/lin 86/64

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

Сначала доходим до конца цикла, дожидаемся все незаблокированные задачи, потом начинаем цикл заново, исполняя все незаблокированные задачи еще раз. Заблокированные же ждут пока их не разблокируют, после чего в следующем цикле продолжают свою работу с той точки, где были заблокированы.


AkinaЗадача должна иметь свойство, устанавливающее, что она заблокирована. Соответственно проверять на входе, и если блок - то сразу выход, а если нет, то выполняется. И соответственно она должна сама "вести" свой счётчик-свойство, буде надо. В общем, она должна быть самодостаточной.
Само собой, должен быть некий диспетчер, который запускает некую задачу, ждёт её завершения, после чего запускает следующую по циклу задачу. Вероятно, также с аналогичным свойством, блокирование коего аналогично блокированию сразу всех задач. Что он при этом будет делать - ждать разблокировки и продолжать, или завершаться - также может быть определено присвоенным этому свойству значением.Сейчас так примерно и сделано.
Проблема началась с того, что основная функция задачи начинает дергать функции ресурсов, при этом может уйти в глубину на 20-30 вызовов и где-то там в конце заблокироваться.

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

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


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

Dimitry SibiryakovAklinПри скорости исполнения с 100к задач в секунду будет скажем 30к синхронизаций в секунду, пул потоков такое не вытянет.
Вытянет, никуда не денется. Создаёшь очередь задач и поток, который задачу из очереди выбирает и исполняет. Соответственно задачи жёстко выполняются в том порядке в котором ты их в очередь засунул.

Не знаю что ты называешь "полной синхронизацией", но всё решается недобавлением задачи Х в очередь пока задача У не прислала квиток о своём выполнении.Я понял.
Думал речь идет про ОС-потоки.


Сейчас по сути так и сделано.
Есть список активных задач, который просто по кругу вращается.
Проблема вот в чем.
Задача начинает дергать функции ресурсов, порой на глубину в 20-30 вызовов и где-то там может быть заблокирована. Вернуться в основной цикл и передать управление на следующей в списке задаче несложно.
Сложно продолжить исполнение с той точки, где произошла блокировка. Приходится вводить множество различных счетчиков состояний чуть ли не на каждом уровне вызова, а потом еще не запутаться в них (состояние еще будет зависеть от вызывающего и т.д.).

alex55555Сколько там в очереди на последовательную обработку - не интересно. Интереснее сколько очередей. Их не более 20. То есть нужно как-то планировать исполнение не более 20 потоков. Ну и в чём проблема-то? Оно даже уже реализовано, оно работает, но что-то не устраивает, только вот сформулировать не получается. Поэтому нужно терзать вопросами до появления понимания - чего, собственно, не нравится-то?Потоков каких - ОС-потоков?

AkinaAklin?? задачи вызывают друг друга? что за ресурсы, откуда цепной вызов? или рекурсия, что один хрен...Задачи не вызывают друг друга.
Задачи могут дергать одни и те же ресурсы.
После завершения или блокировки задачи управление возвращается в диспетчер.
После разблокировки задачи надо продолжить с того же места, на котором задача встала, включая всю иерархию стеков.

Dima TЯ правильно понимаю что есть цепочки задач с подзадачами например:
1. A()->B()->C()
2. D()->E()
Допустим первая "зависла" на вызове С и ты в этот момент хочешь вернуться в основной цикл и запустить вторую, потом закончить первую?
ABCDE - задачи, abcde - ресурсы.

Нормальное исполнение (с учетом ресурсов) будет примерно такое:
(SCHEDULER) -> A(a(b(c(d(...(e))))) -> (SCHEDULER) -> B(c(d(a(b)))) -> (SCHEDULER) -> C(d(g(a)c)))) -> (SCHEDULER) -> A(a(b(c(d[BLOCK] -> (SCHEDULER) -> B(...) -> ... -> (SCHEDULER) -> [BLOCK](e))))) -> ...

Собственно при следующем исполнении задачи А нужно начать с того же места где она была заблокирована, не повторяя весь ее путь с начала.

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

maytonAklinВ среднем за секунду исполняется от 30к до 1м задач.

При одном миллионе задач в секунду у нас длительность одного сеанса задачи = 1мс.
Это та самая граница где КМК надо уходить от мультизадачности в другую сторону.
Сабж у нас был на эту тему.Про современную многозадачность который?

Пытаюсь осилить, пока плохо дается.


от 30к до 1м - это реальное исполнение числа задач в секунду. Но тут правда оговорка.
Задачи есть всегда, то есть конвейер задач забит, и процессор постоянно что-то молотит. В зависимости от сложности задачи ее исполнение занимает чуть больше или чуть меньше времени. Если все задачи закончились, значит программа завершена.

А не так, что если нет задач, то программа прохлаждается.

Dima TТ.е. запустил задачу, в начале получил все необходимые ресурсы, затем сделал полезную работу.
На начало работы задачи я, во-первых, не знаю какие там будут использованы ресурсы (не, конечно можно продублировать работу задачи, сделав две ветки: выделение ресурсов как предварительное исполнение и само исполнение как таковое, но смысла в этом не вижу пока что), а во-вторых, блокировка ресурсов зависит от результата работы многих задач, я заранее это никак не отслежу, пока не попытаюсь достучаться до ресурса.

Dima TМне кажется нет ничего хорошего в этом направлении. По сути ты изобретаешь собственную многопоточность. В этом случае проще разобраться как пользоваться уже имеющейся (потоки ОС).Сейчас пытаюсь сочинить пример попроще, для оценки возможностей пула потоков и времени их переключения.

Пока что у меня ощущение что время переключения одного потока соизмеримо с временем работы одной задачи. А останов пустых потоков занимает больше времени чем исполнение сотни задач. Не могу точно сказать, как заработает пример - будет яснее...

Dima TЭто заранее созданные потоки, которые висят и ждут когда ты в них что-то запустишь.Я боюсь, что пары-тройки потоков мне может не хватить (в случае, например, если десяток будут висеть на заблокированных задачах), а делать 30 потоков, которые выжирают процессор под ноль мне нельзя...


Dimitry SibiryakovА вот это плохо. Надо найти причину блокировки и убить. Насмерть.
Как раз не надо. Блокировка задачи - ожидаемое поведение, а не проблема. Задачу в какой-то момент нужно приостановить до определенной отмашки.

ХитроглазыйAklin,
а что с ресурсами происходит пока задача заблокирована?
остаются занятыми? дедлоков не боитесь?Нет, ресурс блокирует определенную задачу, но при этом продолжает отвечать остальным задачам. Даже если дедлок будет (хотя это скорее невероятно чем маловероятно), то это можно считать нормальным поведением.


ХитроглазыйAklin,

а в целом совсем не ясно в чём вы видите проблему.

Aklinчисло блокировок начинает расти.
и что?Сложность кода ресурсов и самих задач должна быть увеличена раз в десять чтобы обрабатывать новые запросы...



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

alex55555И очень печально, что ты этих азов не знаешь.
Речь не про это.
Речь про различие между каким-нибудь fiber и thread или coroutine