OberonCore

Active BlackBox не вносит никаких изменений в компилятор. Это только рантайм-механизмы.
Так что генерировать параллельные инструкции Блэкбокс не начнёт.

Перенесено отсюда: viewtopic.php?p=39241#p39241
А никто не пробовал для этого дела использовать ActiveBlackBox?

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

Да, Active BlackBox развиваться не будет никогда.

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

Всем привет!

Давно я BB не занимался - немного не в курсе. В последних сборках BB (не ABB) менеджер памяти корректно с несколькими потоками работает или все так же?
А то есть необходимость загрузить ядра. ABB использовать не охота, а отдельные процессы городить и данные по сетке гонять - тяжеловесно получается, вот и думаю WinApi threads и шина сообщений.

Ну... Гоняйте через разделяемую память. Или грузите несколько ББ в одно пространство (можно как DLL, самый простой способ). И гоняйте максимально эффективно бинарные данные (например, выгруженные в файл в памяти Stores).

Но пространство модулей и динамич. объектов будет у каждого ББ своё (и как раз про несколько потоков в одном объектном пространстве Info21 и говорит).

Т.е. компилировать модуль в dll и грузить потом несколько таких dll с помощью rundll32? Или имеется в виду что-то другое?

Основной ББ как EXE, а сателлиты втягиваются в то же адресное пространство как DLL. Правда, надо извернуться чтобы загрузить несколько раз.

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

Все-таки не совсем понятно, что тут означает одно пространство? Сборщик мусора ведь должен быть у каждого ББ свой? Разве это не означает, что экземпляры ББ работают в различных адресных пространствах?

Объектные пространства языка - разные (все объекты, модули, данные языка не пересекаются).

Но адресное пространство ОС - одно.

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

Например, кусок памяти, доступный всем ядрам через интерфейс Files.File.

А уже через такое можно сериализовать объекты языка (те же Stores).

Нет, через System не вкусно. Теряются преимущества сборки мусора и проверки типов. Хотя как вариант без порождения процессов пойдет.
З.Ы. напоминает проблемки в Delphi при работе с dll (тоже у всех свои менеджеры памяти и RTTI), там я это с помощью интерфейсов обходил. Надо будет и тут попробовать.

Почему невкусно? Вы не будете использовать SYSTEM в прикладном коде. Будете работать через обёрнутый Files.File.
Передавать Stores в сериализованном виде. Это один из возможных вариантов.
Надёжность полная.

Можно записывать RECORD, с ASSERT на то, что в ней нет указателей. Можно записывать для дополнительного контроля fingerprint типа...

ещё можно шину сообщений использовать, сообщения как раз сериализуются, как раз RECORD, и как раз асинхронные
вполне рабочий образец сбора/разбора RECORD в xml можно увидеть здесь, например.

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

Как раз шину сообщений и думаю использовать, но без сериализации, а на COM-интерфейсах. Так накладные расходы меньше.

зачем xml? я имел ввиду, что разбор и сбор возможен средствами meta и ядра, а сериализовать можно во всё, что угодно