Здравствуйте! В общих чертах то, что мне требуется — этакий аналог Gearman, но только внутрипроцессный. У нас могут быть задания разной степени сложности. Реализация задания может либо сразу всё синхронно сделать и дать результат, либо что–то поделать и ответить, что работа ещё не сделана, в этом случае нужно в другом потоке периодически давать управление этому заданию, чтоб оно могло продвигаться. При этом можно использовать асинхронный опрос состояния задачи. Многие реализации грешат тем, что в них есть только один способ работать, синхронно или асинхронно. В моём случае обработчик задачи должен сам определить свой режим работы. Оба варианта должны быть доступны. Задачи должны уметь образовывать ацикличный граф или хотя бы дерево зависимостей друг от друга. Если вспомогательная задача надолго, и после выполнения этой вспомогательной задачи нужно сделать ещё какие–то действия, то это должно реализовываться в виде более главной задачи. Планировщик пробудит ожидающую задачу, когда будет закончена вспомогательная. Задач может быть очень много, так что большинство из них protected, а не task. Вспомогательная задача может завершиться неудачно, но может иметь смысл делать повторные попытки с экспоненциально увеличивающимися интервалами. Вот какую–то такую вещь надо бы найти, если есть. А если нет, может, подскажете, чего бы почитать. С уважением, Левашев Иван -- If you want to get to the top, you have to start at the bottom
On Fri, 22 Feb 2013 02:20:51 +0700, you wrote: > Задачи должны уметь образовывать ацикличный граф или хотя бы дерево > зависимостей друг от друга. Если вспомогательная задача надолго, и после > выполнения этой вспомогательной задачи нужно сделать ещё какие–то > действия, то это должно реализовываться в виде более главной задачи. > Планировщик пробудит ожидающую задачу, когда будет закончена > вспомогательная. Задач может быть очень много, так что большинство из > них protected, а не task. > > Вот какую–то такую вещь надо бы найти, если есть. > > А если нет, может, подскажете, чего бы почитать. Data-driven architecture/design/machine? http://en.wikipedia.org/wiki/Data-driven programming -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Dmitry A. Kazakov пишет: > Data-driven architecture/design/machine? > > http://en.wikipedia.org/wiki/Data-driven_programming > Ну если уж на то пошло, то и Functional reactive programming, и Reactive demand programming можно соотнести, но там ещё не до конца исследованное поле экспериментов. Направление интересное, но в деталях эксперименты ещё продолжаются. Я пока в сторонке смотрю на всё это дело, для себя я бы предпочёл что–нибудь типа batch sheduler, но так, чтобы и синхронный, и асинхронный режимы работы были, и решение о выборе режима должен принимать обработчик задания. -- If you want to get to the top, you have to start at the bottom
On Fri, 22 Feb 2013 12:33:07 +0700, you wrote: > Dmitry A. Kazakov пишет: > >> Data-driven architecture/design/machine? >> >> http://en.wikipedia.org/wiki/Data-driven programming >> > Ну если уж на то пошло, то и Functional reactive programming, и Reactive > demand programming можно соотнести, но там ещё не до конца исследованное > поле экспериментов. Ага, как себя помню, так оно и было. Каждое новое поколение на эти грабли наступает. А потом, подрастает производительность "железа", и можно опять забыть это безобразие. > Направление интересное, но в деталях эксперименты > ещё продолжаются. Неважно как называть, важен принцип - никогда, ни при каких обстоятельствах, так не делать, если нет очень веских на то причин, как например данность "железа" или middleware работающих по данному принципу, при сильно ограниченных ресурсах. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
День добрый! Посмотрите на мою библиотеку Concurrent. Она делалась для подобных задач. Я думаю, если понравится, то сможете доработать. Обещаю в течении нескольких дней дать доступ в git. -- Сергей
22.02.2013 16:03, Sergei Lodyagin пишет: > > > День добрый! > > Посмотрите на мою библиотеку Concurrent. Она делалась для подобных > задач. Я думаю, если понравится, то сможете доработать. Обещаю в > течении нес 082;ольких дней дать доступ в git. Не гуглится -- If you want to get to the top, you have to start at the bottom
> Многие реализации грешат тем, что в них есть только один способ > работать, синхронно или асинхронно. В моём случае обработчик задачи > должен сам определить свой режим работы. Оба варианта должны быть доступны. Передумал, переосмыслил. Всё же в разных потоках делается запуск. Только рабочие потоки не лениво периодически посматривают в очередь, а упёрлись в protected entry Get_Job своего координатора и начнут работать сразу же, как поступит задание. А любую задачу можно подождать с таймаутом, упёршись в её protected entry Wait_For_Done. И всё упростилось до некоторой степени. > Задачи должны уметь образовывать ацикличный граф или хотя бы дерево > зависимостей друг от друга. Если вспомогательная задача надолго, и после > выполнения этой вспомогательной задачи нужно сделать ещё какие–то > действия, то это должно реализовываться в виде более главной задачи. > Планировщик пробудит ожидающую задачу, когда будет закончена > вспомогательная. Задач может быть очень много, так что большинство из > них protected, а не task. Теперь другие проблемы. Вот именно это я пока не смог реализовать. Задачи могут находиться в состоянии ожидания, и, если рабочий пытается выяснить, а чего же они ждут, чтобы исполнить то, чего они ждут, мы идём в одном направлении. Если бывшая заблокированной задача хочет уведомить рабочих, которые хотят завершения надзадач, мы идём в обратном направлении. И из–за этого у меня возможны тупики. Какой–то стройной картинки в голове не получается, как бы так сделать, чтобы без race conditions и deadlocks всё работало. То, что мне нужно — это некий гомоморфизм из task+protected в protected+runtime+task pools. На входе у нас обычные tasks и protected. Как вариант, в терминологии POSIX, потоки, мьютексы, условные переменные, рвлоки. И потоков много, больше, чем можно создать на современных OS. Десятки тысяч. На выходе после преобразования у нас куча фрагментов кода, защищённых protected. Выполняется это всё в пулах потоков. Вместо мьютексов какие–то другие структуры и процедуры runtime, которые извлекают или помещают обратно задачи из пула активных в неактивные и обратно. Аналогично условные переменные заменяются каким–то надёжным механизмом подписки, делающим задачи неактивными и пробуждающим обратно при наступлении события. Вместо контекстов на стеке контексты в динамической памяти. Сейчас это то, во что я упёрся. Я так полагаю, алгоритм преобразования первого во второе есть, но мне он неизвестен, и изобрести сходу не получилось. Наверное, я бы смог реализовать планировщик, если всё планирование вынести в единственную задачу или единственный protected, отдельный от рабочих задач. Мне почему–то кажется, что подписку и уведомления в многопоточной среде можно сделать и без этого. Надёжно, стройно и без однопоточного планировщика. План Б сейчас — не использовать свой механизм подзадач, а вместо этого, если задача типа X может зависеть от задачи типа Y, то X и Y выполняются в разных пулах потоков, и одна задача ждёт завершения другой обычными межпоточными средствами. Как обычно, интересует, что можно почитать. Есть ли какой–то термин для описанного преобразования? -- If you want to get to the top, you have to start at the bottom
Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти