OberonCore

А возможно ли "заставить" GC в BB выделять и собирать память в каждом потоке по отдельности (+вожможность передавать объекты между потоками).
Т.е. в каком потоке память выделена, в таком и проверяются на нее ссылки.

Да о том и речь, что дорабатывать Kernel надо. Но нужно как раз-таки научить GC трассировать ссылки одновременно по всем потокам. А вот выделение для каждого потока по отдельности не только не имеет смысла, но и вообще не позволительно: вся безопасность летит к... А если ссылка ушла из стека потока куда-нибудь еще? А GC ее прибил? Висячая ссылка - вещь небывалая в КП

Не понял, куда ушла... ?

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

Плюсы: уход от проблем блокировок (а следовательно сокращение учасков синхронного кода) и упрощение менеджера памяти (опять же не надо мудрить с блокировками).

Как раз в духе оберона (упрощение) как мне кажется.

Тогда идею почти понял. Интересная идея. Однако запретить передачу ссылок между потоками напрямую сложно. Точнее, на уровне синтаксиса КП вообще невозможно. А "джентльменское соглашение" - слишком эфемерная штука и как раз не в стиле Оберона.

Поэтому мне кажется, что лучше не изобретать особых механизмов, а просто расширить стандартный менеджер.
А если требуются более сложные концепции - Zonnon & Active Oberon are welcome.

И синтаксис и джентельменские соглашения тут ни при чем, а вот среда исполнения - ДА. Просто создавать новый поток среда должна как бы с "чистого листа", не передавая ни создавшему поток, ни "потоковой функции" никаких указателей друг на друга. При этом все глобальные переменные должны быть для потока уникальными. Нет ни одной сслыки - следовательно новой возникнуть неоткуда.

Самый простой способ - запускать новую копию среды для каждого потока (в отдельном процессе), но ресурсов будет отниматься много. А вот если бы инициализировать только "память контекста" (подчти как у ДЛЛ для каждого процесса в винде) - все было бы Ок.


Это оно конечно да, но это самое расширение задача соооосовсем не простая! Есть два варианта:
1) моментально останавливать все потоки процесса на момент сбора мусора, а это само по себе нетривиально в винде. Причем останавливать желательно в "правильных" местах, а не между загрузкой указателя в регистр и перед записью его в стек напрмер (тогда такой указатель будет ой как сложно искать в стеке).
2) не останавливать потоки, а собирать мусор в фоновом режиме, что скорее всего не предусмотрено в компиляторе (а для этого требуется введение всяких хитростей типа дополнительных меток в сервисных структурах блоков выделенной памяти и т.п.)


В том то и дело, что хотелось бы попроще чем в Zonnon, к томуже он еще не готов и пока только под .НЕТ (а Active Oberon тут вообще не причем).

Прелесть потоков как раз в общем разделяемом адресном пространстве. И это их основное отличие от процессов.

У Рихтера это звучит примерно так:
- Поток есть поток передачи управления, т.е. последовательность прохождения команд программы.
- Процессом традиционно называют совокупность всех ресурсов компьютера, отданных операционной системой для выполнения программы (В т.ч. и потоки).

В принципе потоки не обязаны разделять общее адресное пространство (и даже в винде это возможно), однако некоторый набор ресурсов процесса - да.

Я не спорю, что для ряда задач УДОБНО иметь именно разделяемое адресное пространство, однако практика показывает что число таких задач невелико, и их всегда можно реализовать как низкоуровневые модули с использованием, например, пойнеров из SYSTEM. В частности сам механиз передачи сообщений должен быть реализован именно так.

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

Работу через механизм передачи сообщений можно наблюдать в COM для случая MTA. Я бы не сказал, что это очень удобно и единственно правильно.



Это уже другой вопрос... Но среда разработки под винду без поддержки многопоточности сильно ограничивает круг задач.

COM - не язык а протокол, и я предполагаю что МОЖНО реализовать достаточно удобный синтаксис для некоторого гипотетического языка в котором ЭТО будет удобно. И я ЭТО не предлагаю использовать.


Это (уже не COM ) точно НЕ ЕДИНСТВЕННО правильная, но все же достаточно хорошая концепция, имеющая ряд приемуществ. Ее, в частности, часто используют на больших машинах (даже SMP) для решения тяжелых задач.


Абсолютно согласен. К сожалению для меня это ОЧЕНЬ большой барьер для использования BB - остуствие ПОДДЕРЖКИ параллельного программирования хотя бы в каком-то виде.

ИМХО, синтаксис мало чего даст. Синтаксически оно даже в C++ выглядит вполне красиво: interface->method(). Но вот как на уровне гипотетического синтаксиса избавиться от понятия маршаллинга и цикла выборки сообщений - я сейчас не очень представляю.

Маршаллинг - всего лишь межпроцессный вызов процедур, который может быть и синхронный (напрмер между компьютерами в сети). А вот цикл выбора сообщений - конкретная рализация механизма передачи сообщений (в частности с использованием механизма маршаллинга). И сиснтаксис может "изолировать" пользователя от самого этого цикла. Самый простой пример - message методы в дельфе. Более сложный: механизм Channels в исследовательской разработке Microsoft - OS Singularity (где для обеспечения устойчивости как раз и запрещается обмениваться указателями между потоками). Нечто идеологически "похожее" реализованно в Zonnon, правда без изоляции по памяти. Но на мой взгляд все это "несколько" сложновато.

Алексей, а кто такие эти пойнеры? Касательно Вашего предложения - можно ли увидеть код запускающий какой-нибудь служебный поток. В своем контексте, но с изоляцией от основного потока. Кстати, если основной поток закрыть - он закроется?

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



И в чем его особенность?

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

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

Пока о системе речь не шла вроде. Да и не спорить моя задача, понимаешь. Есть задачи в которых приемлемо использовать событийно-ориентированную модель. Вот моя задача и состоит в том, чтобы разобраться как её эффективнее реализовать. Может быть вы знаете, что Алексей под пойнерами имел в виду? Глупый вопрос?

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



Поинтеры?

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


В ББ - нет (мной не написано). А вообще через эти самые ПОЙНЕРЫ множно легко сделать, только вот это уже "извращение" какое то получается. Зачем тогда ББ использовать? Лучше модула если без сборки мусора. По этому поводу и был задан мой первый вопрос в этой ветке. Правильнее его сформулировать наверное так: можно ли заставить ББ в новом потоке заново проинициализировать все требующиеся модули, без привязки к "глобальным" переменным. Мне кажется что это возможно (и думаю проще чем переписывать сборщик мусора).

На самом деле ничего придумывать не надо. Теоритечески можно показать (и уже давно показано) что механизмы передачи сообщений полностью эквивалентны по возможностям синхронизации потоков "классическим" объектам синхронизации (таким как в винде например).
Другое дело что если адаптировать программу "в лоб", заменяя каждый объект синхронизации соответсвующим кодом основанным на передаче сообщений, то эффективности никакой не будет (особенно с учетом "эмуляции" общей памяти). Но это не значит что нельзя переработать конкретный алгоритм так, что он будет эффективно реализовываться в системе с передачей сообщений. И в цикле выборки сообщений нет ничего плохого: примерно то-же часто происходит при использовании критических секций или мутексов в цикле, просто "взгляд" другой. А использование событийного механизма в гуях не образец - это изначально вообще однозадачная система (win3x). В реальных же задачах поток не один и не два, и очередей много (коммуникаторы по "классике").


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

Не обязательно лично Вами. Вы ведь говорили о конкретном решении. Мой вопрос звучал: доступен ли его код. Относительно того чтобы модули инициализировались без привязки к глобальным переменным сомнительно что-то. Тем более интересно увидеть этот механизм.
P.S. Предлагаю называть память не участвующую в сборке мусора свободной. Коротко и ясно от чего.