AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.11.2017, 15:24   #1  
Rardd
Гость
 
n/a
Синхронизация потоков в АХ7
Здравствуйте,
Подскажите пожалуйста как правильно делать синхроницазию потоков в АХ7.
Есть несколько методов которые запущены асинхронно через Global::runAsync, и нужно результат этих методов записывать в некий список :

static List list;
static Object locker;
...
try
{
System.Threading.Monitor::Enter(locker);
list.addEnd(returnValue);
}
finally
{
System.Threading.Monitor::Exit(locker);
}

в результате список пуст, может кто-то сталкивался
Старый 15.11.2017, 15:27   #2  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от Rardd Посмотреть сообщение
в результате список пуст, может кто-то сталкивался
Статические поля в X++ они в рамках сессии. Возможно это не один и тот же список.
Старый 15.11.2017, 15:45   #3  
Rardd
Гость
 
n/a
А как тогда создавать обьекты которые можна изменять в разных потоках? В С# есть volitile переменные, я думаю что и в Х++ должна быть схожая функциональность...
Старый 15.11.2017, 16:38   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Rardd Посмотреть сообщение
А как тогда создавать обьекты которые можна изменять в разных потоках? В С# есть volitile переменные, я думаю что и в Х++ должна быть схожая функциональность...
А чем вас таблица и база данных как хранилище не устраивает?
Почему именно список?
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: trud (2).
Старый 15.11.2017, 17:16   #5  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от Rardd Посмотреть сообщение
, я думаю что и в Х++ должна быть схожая функциональность...
X++ создавался совершенно для других целей. Так что не думаю, что не должна.

Если надо что-то этакое, можно написать на C# (правда, как это паковать и развертывать клиенту я не знаю).

Присоединяюсь к вопросу mazzy
Старый 15.11.2017, 17:17   #6  
Rardd
Гость
 
n/a
Цитата:
Сообщение от mazzy Посмотреть сообщение
А чем вас таблица и база данных как хранилище не устраивает?
Почему именно список?
Можно и не список, подойдет любая другая структура данных.
Ситуация такова что нету доступа к БД, и все нужно хранить "здесь и сейчас"...Столкнулся просто и хотелось бы понять
Старый 15.11.2017, 17:28   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Rardd Посмотреть сообщение
Ситуация такова что нету доступа к БД, и все нужно хранить "здесь и сейчас"...
Что вы такое делаете?
Многопоточное и не имеющее доступа к базе данных.

Цитата:
Сообщение от Rardd Посмотреть сообщение
Столкнулся просто и хотелось бы понять
Аксапта - многопользовательское приложение, которое хранит свои данные в единой базе данных.
База данных в аксапте - самый естественный способ хранить данные из разных сессий/потоков.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили:  (1).
Старый 15.11.2017, 17:46   #8  
Rardd
Гость
 
n/a
Цитата:
Сообщение от mazzy Посмотреть сообщение
Что вы такое делаете?
Многопоточное и не имеющее доступа к базе данных.
Чутка не так выразился
Мне не хотелось бы просто писать в таблицы.
Спасибо за ответ!
Старый 15.11.2017, 17:53   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Rardd Посмотреть сообщение
Мне не хотелось бы просто писать в таблицы.
в акс7 есть класс SysGlobalObjectCache. он синхронизирует хранимые данные между сессиями. но ничего не гарантирует.

Не перепутайте с SysGlobalCache. Этот хранит только внутри сессии.

посмотрите как используется.
и не делайте так.

побочные эффекты такого лечения хуже болезни.
храните межсессионные данные в таблицах.
а уж бд будет заботиться и о тразакционной целостности, и о валидации и о блокировках и о производительности.
__________________
полезное на axForum, github, vk, coub.
Старый 16.11.2017, 04:02   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Подозреваю что ваша цель - это ускорить какую-то операцию за счет разбития ее на куски и параллельного выполнения?
если так, то есть отличная статья как это делать
https://blogs.msdn.microsoft.com/axp...-in-ax-part-i/
За это сообщение автора поблагодарили: mazzy (2), belugin (5), AlGol (2), Sergey Petrov (1).
Старый 16.11.2017, 20:49   #11  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от 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
Старый 17.11.2017, 03:10   #12  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
На одном из проектов AX2009 в который меня пригласили разгребать, очень неплохие вдумчивые программисты C# весь основной фунционал сопряжения с конвейером написали как раз на потоках используя X++. В результате если AOS не падал пару раз за день, то значит это был выходной. А все из-за того что искали аналоги, а о существовании пакетных запусков (batch jobs) просто не подозревали.

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

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

Ослиный мостик эти потоки.
За это сообщение автора поблагодарили: eugene egorov (2), Logger (1).
Старый 17.11.2017, 14:42   #13  
f18 is offline
f18
Участник
Аватар для f18
Дети Юза
 
188 / 101 (4) +++++
Регистрация: 09.08.2005
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Потоки в 2012 не перенесены на выполнение в CIL. На клиенте они работают норм, но не в CIL. MS ребята подтвердили что они их и не перенесли - небыло поставлено такой задачи.
За это сообщение автора поблагодарили: Logger (2), ax_mct (2).
Старый 17.11.2017, 16:55   #14  
Rardd
Гость
 
n/a
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Статья про использование batch framework без прямой работы с потоками (то есть с threads). И это хорошо.

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

Thread Class
https://msdn.microsoft.com/en-us/library/thread.aspx
Я понимаю что придумывать велосипеды не очень хорошо, ведь они в результате приведут к стандартному функционалу аксапты. Но если разбивать задачу на подзадачи с помощью батча, то это все равно один поток. Была задача сделать это в разных потоках и изначально я не хочел писать это в таблицу в БД, а использовать структуру-колекцию, потому-что доступ к БД и запись, это все время. Мало того, я сделал асинхронный запуск методов что пишут в таблицу и обнаружил что в таком режиме вставлялись по 4 записи, тоисть SQL держит записи в очереди и как только есть 4, он вставляет и берет следующие. А если можно было бы делать синхронизацию потоков, то все вставлялось бы по очереди.
Спасибо

Последний раз редактировалось Rardd; 17.11.2017 в 17:00.
Старый 18.11.2017, 13:04   #15  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Rardd, в ваших словах мелькает слово
"нужно". И то что нормальный подход с записью в таблицу - это "время".
Если это ваши собственные эксперименты в песочнице то это одно,
но если это бизнес-требования то не могли бы вы ими поделиться.
Возможно мы предложим достойные альтернативы.

Обычно скоростью лучше жертвовать во имя поддержки и надёжности.
У нас ведь задача не гонку выиграть, а груз со склада на склад довести.
Старый 05.12.2017, 18:58   #16  
Rardd
Гость
 
n/a
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Если это ваши собственные эксперименты в песочнице то это одно,
но если это бизнес-требования то не могли бы вы ими поделиться.
Возможно мы предложим достойные альтернативы.

Обычно скоростью лучше жертвовать во имя поддержки и надёжности.
У нас ведь задача не гонку выиграть, а груз со склада на склад довести.
Извините за задержку с ответом. Задача в следующем:
Есть сущность которую нужно выгружать, и есть ситуация когда эта сущность настолько велика, что ее формирование это десятки часов (система достаточно мощная). И задача была в том, что бы разбить выгрузку этой сущности на потоки что бы снизить общее время ее генерации так как есть записи которые выгружаются 10 секунд, а есть записи которые выгружаются 10 минут, и пришли к выводу что нужно разбить выгрузку на задачи (потоки). Каждый поток записывает резульатат в таблицу (единственный выход синхронизации потоков). Потом, когда все потоки отработали, идем в таблицу и создаем из записей json, который с помощью Custom Service можна забрать. Вот собственно и все
Старый 05.12.2017, 20:46   #17  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Ну нормальная такая задача. Есть таблица, которая заполняется неким алгоритмом расчета и эта таблица большая. Допустим, это проводки по номенклатуре. Если разбить алгоритм на потоки и приравнять 1 поток = 1 номенклатура, то выгрузка будет неравномерной (по какой-то номенклатуре движений больше, а по какой-то меньше).

Так вот - в этой задаче не вижу проблем поместить этот список потоков в отдельную таблицу. Количество потоков всяко будет на много порядков меньше количества записей в этой сущности. Зачем извращаться с List-ом?
__________________
Возможно сделать все. Вопрос времени
Старый 05.12.2017, 23:16   #18  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от 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. На выделенном сервере, по расписанию, с параметрами и пр.

Не нужна вам никакая синхронизация потоков.
Старый 05.12.2017, 23:37   #19  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Rardd Посмотреть сообщение
Извините за задержку с ответом. Задача в следующем:
Есть сущность которую нужно выгружать, и есть ситуация когда эта сущность настолько велика, что ее формирование это десятки часов (система достаточно мощная). И задача была в том, что бы разбить выгрузку этой сущности на потоки что бы снизить общее время ее генерации так как есть записи которые выгружаются 10 секунд, а есть записи которые выгружаются 10 минут, и пришли к выводу что нужно разбить выгрузку на задачи (потоки). Каждый поток записывает резульатат в таблицу (единственный выход синхронизации потоков). Потом, когда все потоки отработали, идем в таблицу и создаем из записей json, который с помощью Custom Service можна забрать. Вот собственно и все
Вам идеально подходит Batch в режиме multithread http://www.artofcreation.be/2010/10/...ultithreading/ лучше для задачи не придумаешь. BatchJob будет сплититься на потоки, один из которых master, после того как все остальные отработают будет осуществлять выгрузку. Из преимуществ - в случае «пропало электричество» продолжит свою работу + логи, регулирование количества потоков, повтор в случае отказа, нотификация по завершению и т.д. Одним словом - все плюшки батча.

Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать. Его сложно отлаживать, нужно засинкать потоки, оптимизировать их количество, корректно вернуть результат из потока + вероятно вернуть infolog и т.д. Все это нетипичное для повседневных задач программирование, отсюда его не любят. Однако, работу он свою выполняет корректно, без мифических глюков и не раз выручал. В CIL он действительно не работает, но и не очень-то нужно. Threads больше подходит для интерактивных задач.
Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое.
За это сообщение автора поблагодарили: user_ax (2), Sergey Petrov (1).
Старый 06.12.2017, 00:08   #20  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вам идеально подходит Batch в режиме multithread
...
Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать.
...
Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое.
Потоки действительно уместны для фонового выполнения чтобы не мерзла форма, но там где мы берем из DB (полагаю что не из файлов) и кладем в DB, как потоки не готовь они останутся не к столу.

Кстати как вариант я бы еще рассматривал средства СУБД и хранимые процедуры.
Теги
async, ax2012, ax7, cil, d365 for operations, lock, thread

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AX2012R3: полная синхронизация данных POS-магазина PTG DAX: Функционал 10 22.06.2016 17:43
Синхронизация SP4 -> SP5 Logger DAX: Программирование 4 09.08.2006 13:10
навязчивая синхронизация Антон Солдатов DAX: Функционал 11 22.04.2005 11:04
Репликация и синхронизация Tays DAX: Администрирование 12 24.11.2004 12:18
синхронизация с outlook alpine DAX: Функционал 7 09.06.2004 13:53
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.