Синхронизация потоков в АХ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);
}

в результате список пуст, может кто-то сталкивался

[belugin]

Цитата:

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

в результате список пуст, может кто-то сталкивался

Статические поля в X++ они в рамках сессии. Возможно это не один и тот же список.

А как тогда создавать обьекты которые можна изменять в разных потоках? В С# есть volitile переменные, я думаю что и в Х++ должна быть схожая функциональность...

[mazzy]

Цитата:

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

А как тогда создавать обьекты которые можна изменять в разных потоках? В С# есть volitile переменные, я думаю что и в Х++ должна быть схожая функциональность...

А чем вас таблица и база данных как хранилище не устраивает?
Почему именно список?

[belugin]

Цитата:

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

, я думаю что и в Х++ должна быть схожая функциональность...

X++ создавался совершенно для других целей. Так что не думаю, что не должна.

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

Присоединяюсь к вопросу mazzy

Цитата:

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

А чем вас таблица и база данных как хранилище не устраивает?
Почему именно список?

Можно и не список, подойдет любая другая структура данных.
Ситуация такова что нету доступа к БД, и все нужно хранить "здесь и сейчас"...Столкнулся просто и хотелось бы понять

[mazzy]

Цитата:

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

Ситуация такова что нету доступа к БД, и все нужно хранить "здесь и сейчас"...

Что вы такое делаете?
Многопоточное и не имеющее доступа к базе данных.

Цитата:

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

Столкнулся просто и хотелось бы понять

Аксапта - многопользовательское приложение, которое хранит свои данные в единой базе данных.
База данных в аксапте - самый естественный способ хранить данные из разных сессий/потоков.

Цитата:

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

Что вы такое делаете?
Многопоточное и не имеющее доступа к базе данных.

Чутка не так выразился
Мне не хотелось бы просто писать в таблицы.
Спасибо за ответ!

[mazzy]

Цитата:

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

Мне не хотелось бы просто писать в таблицы.

в акс7 есть класс SysGlobalObjectCache. он синхронизирует хранимые данные между сессиями. но ничего не гарантирует.

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

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

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

[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

[ax_mct]

На одном из проектов AX2009 в который меня пригласили разгребать, очень неплохие вдумчивые программисты C# весь основной фунционал сопряжения с конвейером написали как раз на потоках используя X++. В результате если AOS не падал пару раз за день, то значит это был выходной. А все из-за того что искали аналоги, а о существовании пакетных запусков (batch jobs) просто не подозревали.

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

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

Ослиный мостик эти потоки.

[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 можна забрать. Вот собственно и все

[sukhanchik]

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

Так вот - в этой задаче не вижу проблем поместить этот список потоков в отдельную таблицу. Количество потоков всяко будет на много порядков меньше количества записей в этой сущности. Зачем извращаться с List-ом?

[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, как потоки не готовь они останутся не к столу.

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