OberonCore

Возможно я неверно выразился. Я имел ввиду что такой механизм (такие механизмы) существуют и реализованы (много), но для ББ таких реализаций мне не известно. Я использовал подобный механизм реализованный на Модуле2, но там нет сборки мусора. За основу был взят интерфейс MPI (можно посмотреть http://parallel.ru/tech/tech_dev/mpi.html) но кастрированный (специализированное решение).
Тем не менее очевидно, что сборка мусора не является помехой для реализации механизма передачи сообщений.

Нет, ЕГО код не доступен (авторские права), но аналогичные решения есть в открытом доступе в интернете.

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

Можно перепутать с особожденной (уже) или не использованной (еще). Может лучше что то типа независимой?

Давно уже предлагалось запускать для этого сразу несколько Блэкбоксов общающихся друг с другом хоть через TCP, хоть через общие файлы отображенные в память... Причем "вторичные Блэкбоксы", естественно, можно запускать без графического интерфейса (слинковать специальные безграфические версии).

С неиспользованной не перепутаешь, поскольку явно подразумевается её использование сборщиком. Что же касается освобожденной, то у неё нет основания для выделения в отдельную категорию вообще. Если её действительно освободили. Свободная ("несвязанная") явно указывает на отличие от противоположного состояния. Что в сущности и требуется от определения, по-моему.

Угу, "несвязанная" мне нравится, договорились ?

Ну да. Юниксоиды тоже долго кричали: "нафига нам потоки как в винде, если у нас есть крутой fork". Однако во всех приличных юниксах потоки появились.

Вообще-то есть термины связанная и свободная. А "несвязанная" я не встречал пока. Но если Вас неологизмы не пугают, то, пожалуйста, используйте на здоровье. Другой вопрос имеет ли она смысл в Component Pascal. Он ведь не Modula...

Можно ли узнать где распределенная (использованная, занятая) но не "связанная" (со сборщиком мусора) память называется "свободной". В имеющейся у меня литературе свободной называется НИКЕМ и НИЧЕМ не используемая в данный момент память. Именно это пересечение терминов мне и не нравится.

Как раз пугают, поэтому и предлагаю поискать другой термин вместо "свободная".

Раз есть в ББ псевдомодуль SYSTEM c "псевдоуказателями" SYSTEM.ADR, то и хочется как то КРАТКО обозначить то, на что они указывают, а не писать каждый раз развернутое предложение как в документации по ББ.

А вообще это не имеет прямого отношения к теме ветки .

Видимо все-таки не поняли. "Свободная" и "связанная" слова антонимы. Давать термин "свободная" не используемой в данной момент памяти, значит терять это противопоставление впустую. Хотя и не преступление, а обидно. Согласен, что хочется краткости - поэтому и высказал эту идею.
Если модератор сочтет полезным пусть уберет эту дискуссию куда-нибудь, где термины обсуждают. Мы остановились на взаимодействии стандартного и минимизированного BlackBox. Стандартный уже есть, а второй кто-нибудь писал уже?

Я не против "антонимов" , просто имхо надо учитывать уже сложившиеся термины, а определение "свободной памяти" используется повсеместно именно в "моем" смысле, и может случиться просто путаница! Иное дело говорить о свободных указателях. Такого определения я вроде не встречал.


На самом деле вопрос не праздный. Вопрос об определениях очень актуален для "нашего" ИТ. За многие годы "у нас" сложилиась собственная система понятий, плохо согласующаясь с "дословными" переводами "англоязычных документаций". Особенно при введении новых понятий...
Часто происходят именно пересечения терминов, с чем мне приходилось сталкивался в ранних (да и поздние тоже) версиях русскоязычного перевода стандарта ISO 15408.


Конечно, для этого есть специальные средства о коих написано много документации. Самый простой способ - сделать свою сборку модулей со стандартным загрузчиком (в 87 кило). Однако можно и свой ЕХЕ сварить. Правда у меня самого такого опыта нет .

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

Ок. Вариант мне нравится. Договорились!

В принципе, само их ("псевдоуказателей") размещение не имеет значения (во всяком случае для сборщика мусора).

А все указывающие на автономную память - просто "псевдоуказатели", так ?

В смысле псевдоуказатели указывают только на автономную память? Это уже ограничение. Хотя в результате структура и проясняется. Давайте примем пока что псевдоуказатели могут адресовать что-угодно, а там посмотрим.

Конечно же, псевдоуказатели могут указывать на любую память. Вы абсолютно правы!

Могу лишь заметить, что псевдоуказатели на "связанную" память потенциально очень опасны, поэтому их лучше вообще не применять (к тому же это неимеет никакой практической пользы). Так что в дальнейшем предлагаю считать псевдоуказатели ссылающимися на автономную память (если прямо не указано обратного).

Назовите память неуправляемой (unmanaged) и указатели соответветственно. Сразу понятно о чем речь.

Где только Вы видели неуправляемую память. Эта ветка и то под контролем.

Обыденное понятие из .NET.

В Блэкбоксе тоже появятся (когда ни будь). А вот пока они не появились, предлагается запускать несколько Блэкбоксов одновременно. От безысходности предлагается, а не потому что "так лучше". Ваш сарказм излишен.

Как вы оперативно ответили, Vlad. Удивительно даже. В другое время ждешь - не дождешься.
Я впрочем не настаиваю. С точки зрения менеджера она действительно неуправляема им. Но в общем плане о неуправляемости говорить не приходится.
Мой вариант ("автономная") нейтрален. И в дальнейшем я буду использовать именно его.

Термин unmanaged - из другой системы понятий, и, как мне кажется, несколько неуместен в рамках оберон-подобных языков. Хотя базовые идеи положенные в основу .net и "оберона" пересекаются, но все же несколько различны. И термин unmanaged как раз из этой оперы. Программы на "обероне" не "управляются", они просто безопасны, что обеспечивается не фреймворком (как в .net), а синтаксисом языка. Отсутсвует и промежуточное языковое звено (IL ассемблер), так как нет необходимости поддерживать большое семейство родственных языков. Отсюда и большая, по сравнению с .net, производительность - нет необходимости "управлять" потенциально небезопасным кодом (отсутствуют лишние проверки).

Интересно обсудить варианты интерфейса (и реализации тоже) для мезанизма обмена сообщениями. Все же хочется чегой-то простого, в стиле ББ. И сильно не хочется реализовывать что то вроде MPI (даже его подмножество)... Все же это больше для кластеров.

Из своего опыта могу констатировать, что организация очереди сообщений на основе объектов синхронизации видовс эффективнее использования стандартной очереди сообщений (отчасти в силу отсутствия "лишних" сообщений от винды). Кроме этого стандартная очередь начинает вести себя "плохо" при закрытии приложения...