Синхронизация потоков в АХ7

[trud]

Подозреваю что ваша цель - это ускорить какую-то операцию за счет разбития ее на куски и параллельного выполнения?
если так, то есть отличная статья как это делать
https://blogs.msdn.microsoft.com/axp...-in-ax-part-i/

[ax_mct]

Цитата:

Сообщение от trud

Подозреваю что ваша цель - это ускорить какую-то операцию за счет разбития ее на куски и параллельного выполнения?
если так, то есть отличная статья как это делать
https://blogs.msdn.microsoft.com/axp...-in-ax-part-i/

Статья про использование batch framework без прямой работы с потоками (то есть с threads). И это хорошо.

Присоединюсь к тем что кто советует любой ценой избегать прямой работы с threads будь то AX5, 6 или 7. Код такой писать как бы можно, но абсолютно противопоказано.
Просто забудьте о такой возможности чтобы там ни было написано в msdn.

Thread Class
https://msdn.microsoft.com/en-us/library/thread.aspx

[f18]

Цитата:

Сообщение от ax_mct

Thread Class
https://msdn.microsoft.com/en-us/library/thread.aspx

Потоки в 2012 не перенесены на выполнение в CIL. На клиенте они работают норм, но не в CIL. MS ребята подтвердили что они их и не перенесли - небыло поставлено такой задачи.

Цитата:

Сообщение от ax_mct

Статья про использование batch framework без прямой работы с потоками (то есть с threads). И это хорошо.

Присоединюсь к тем что кто советует любой ценой избегать прямой работы с threads будь то AX5, 6 или 7. Код такой писать как бы можно, но абсолютно противопоказано.
Просто забудьте о такой возможности чтобы там ни было написано в msdn.

Thread Class
https://msdn.microsoft.com/en-us/library/thread.aspx

Я понимаю что придумывать велосипеды не очень хорошо, ведь они в результате приведут к стандартному функционалу аксапты. Но если разбивать задачу на подзадачи с помощью батча, то это все равно один поток. Была задача сделать это в разных потоках и изначально я не хочел писать это в таблицу в БД, а использовать структуру-колекцию, потому-что доступ к БД и запись, это все время. Мало того, я сделал асинхронный запуск методов что пишут в таблицу и обнаружил что в таком режиме вставлялись по 4 записи, тоисть SQL держит записи в очереди и как только есть 4, он вставляет и берет следующие. А если можно было бы делать синхронизацию потоков, то все вставлялось бы по очереди.
Спасибо

[ax_mct]

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

Обычно скоростью лучше жертвовать во имя поддержки и надёжности.
У нас ведь задача не гонку выиграть, а груз со склада на склад довести.

Цитата:

Сообщение от ax_mct

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

Обычно скоростью лучше жертвовать во имя поддержки и надёжности.
У нас ведь задача не гонку выиграть, а груз со склада на склад довести.

Извините за задержку с ответом. Задача в следующем:
Есть сущность которую нужно выгружать, и есть ситуация когда эта сущность настолько велика, что ее формирование это десятки часов (система достаточно мощная). И задача была в том, что бы разбить выгрузку этой сущности на потоки что бы снизить общее время ее генерации так как есть записи которые выгружаются 10 секунд, а есть записи которые выгружаются 10 минут, и пришли к выводу что нужно разбить выгрузку на задачи (потоки). Каждый поток записывает резульатат в таблицу (единственный выход синхронизации потоков). Потом, когда все потоки отработали, идем в таблицу и создаем из записей json, который с помощью Custom Service можна забрать. Вот собственно и все

[ax_mct]

Цитата:

Сообщение от Rardd

Извините за задержку с ответом. Задача в следующем:
Есть сущность которую нужно выгружать, и есть ситуация когда эта сущность настолько велика, что ее формирование это десятки часов (система достаточно мощная). И задача была в том, что бы разбить выгрузку этой сущности на потоки что бы снизить общее время ее генерации так как есть записи которые выгружаются 10 секунд, а есть записи которые выгружаются 10 минут, и пришли к выводу что нужно разбить выгрузку на задачи (потоки). Каждый поток записывает резульатат в таблицу (единственный выход синхронизации потоков). Потом, когда все потоки отработали, идем в таблицу и создаем из записей json, который с помощью Custom Service можна забрать. Вот собственно и все

1. Создать runbaseBatch класс который "выгружает".
2. В данном классе использовать Query c нужными вам data ranges (продукт, вендор, дата и пр.).
3. Позаботится об отсутствии конфликтов при вставке в конечную таблицу.
4. Поставить в пакетную обработку столько запусков сколько вам угодно разделяя обработку через значения в data ranges.

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

По сути вы формируете некий data source для внешнего сервиса. Но я очень сомневаюсь обновления данных 1-3 раза в сутки в данном data source будет недостаточно.

А если у вас полный runtime и каждый запрос внешнего сервиса создает новую выгрузку то пожалейте систему и себя. Все равно придете к периодическому формированию data source и его повторному использованию. И здесь надо то что называется "периодическая операция" в AX. На выделенном сервере, по расписанию, с параметрами и пр.

Не нужна вам никакая синхронизация потоков.

[DSPIC]

Цитата:

Сообщение от Rardd

Извините за задержку с ответом. Задача в следующем:
Есть сущность которую нужно выгружать, и есть ситуация когда эта сущность настолько велика, что ее формирование это десятки часов (система достаточно мощная). И задача была в том, что бы разбить выгрузку этой сущности на потоки что бы снизить общее время ее генерации так как есть записи которые выгружаются 10 секунд, а есть записи которые выгружаются 10 минут, и пришли к выводу что нужно разбить выгрузку на задачи (потоки). Каждый поток записывает резульатат в таблицу (единственный выход синхронизации потоков). Потом, когда все потоки отработали, идем в таблицу и создаем из записей json, который с помощью Custom Service можна забрать. Вот собственно и все

Вам идеально подходит Batch в режиме multithread http://www.artofcreation.be/2010/10/...ultithreading/ лучше для задачи не придумаешь. BatchJob будет сплититься на потоки, один из которых master, после того как все остальные отработают будет осуществлять выгрузку. Из преимуществ - в случае «пропало электричество» продолжит свою работу + логи, регулирование количества потоков, повтор в случае отказа, нотификация по завершению и т.д. Одним словом - все плюшки батча.

Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать. Его сложно отлаживать, нужно засинкать потоки, оптимизировать их количество, корректно вернуть результат из потока + вероятно вернуть infolog и т.д. Все это нетипичное для повседневных задач программирование, отсюда его не любят. Однако, работу он свою выполняет корректно, без мифических глюков и не раз выручал. В CIL он действительно не работает, но и не очень-то нужно. Threads больше подходит для интерактивных задач.
Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое.

[ax_mct]

Цитата:

Сообщение от DSPIC

Вам идеально подходит Batch в режиме multithread
...
Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать.
...
Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое.

Потоки действительно уместны для фонового выполнения чтобы не мерзла форма, но там где мы берем из DB (полагаю что не из файлов) и кладем в DB, как потоки не готовь они останутся не к столу.

Кстати как вариант я бы еще рассматривал средства СУБД и хранимые процедуры.

[user_ax]

Цитата:

Сообщение от DSPIC

Вам идеально подходит Batch в режиме multithread http://www.artofcreation.be/2010/10/...ultithreading/ лучше для задачи не придумаешь. BatchJob будет сплититься на потоки, один из которых master, после того как все остальные отработают будет осуществлять выгрузку. Из преимуществ - в случае «пропало электричество» продолжит свою работу + логи, регулирование количества потоков, повтор в случае отказа, нотификация по завершению и т.д. Одним словом - все плюшки батча.

Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать. Его сложно отлаживать, нужно засинкать потоки, оптимизировать их количество, корректно вернуть результат из потока + вероятно вернуть infolog и т.д. Все это нетипичное для повседневных задач программирование, отсюда его не любят. Однако, работу он свою выполняет корректно, без мифических глюков и не раз выручал. В CIL он действительно не работает, но и не очень-то нужно. Threads больше подходит для интерактивных задач.
Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое.

Дал оценку сообщению и добавлю от себя пару слов:
делал похожую задачу используя мультипоточность , которую предлагает стандартный runBaseBatch - все отлично работает, без каких-либо нареканий. И что самое важное - выглядит код действительно проще , нежели с использованием Threads классов.