OberonCore
https://forum.oberoncore.ru/

Введение многопоточности в BlackBox
https://forum.oberoncore.ru/viewtopic.php?f=2&t=110
Страница 1 из 5

Автор:  Алексей Елин [ Суббота, 28 Январь, 2006 00:29 ]
Заголовок сообщения: 

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

Автор:  Илья Ермаков [ Суббота, 28 Январь, 2006 03:53 ]
Заголовок сообщения: 

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


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

Автор:  Алексей Елин [ Воскресенье, 29 Январь, 2006 21:46 ]
Заголовок сообщения: 

Цитата:
А вот выделение для каждого потока по отдельности не только не имеет смысла, но и вообще не позволительно: вся безопасность летит к... А если ссылка ушла из стека потока куда-нибудь еще?


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

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

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

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

Автор:  Илья Ермаков [ Воскресенье, 29 Январь, 2006 23:24 ]
Заголовок сообщения: 

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

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

Автор:  Алексей Елин [ Понедельник, 30 Январь, 2006 00:42 ]
Заголовок сообщения: 

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

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

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

Цитата:
Поэтому мне кажется, что лучше не изобретать особых механизмов, а просто расширить стандартный менеджер.

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

Цитата:
А если требуются более сложные концепции - Zonnon & Active Oberon are welcome.

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

Автор:  Vlad [ Понедельник, 30 Январь, 2006 07:23 ]
Заголовок сообщения: 

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


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

Автор:  Алексей Елин [ Понедельник, 30 Январь, 2006 23:05 ]
Заголовок сообщения: 

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

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

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

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

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

Автор:  Vlad [ Понедельник, 30 Январь, 2006 23:43 ]
Заголовок сообщения: 

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


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

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


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

Автор:  Алексей Елин [ Вторник, 31 Январь, 2006 00:16 ]
Заголовок сообщения: 

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

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

Цитата:
Я бы не сказал, что это очень удобно и единственно правильно.

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

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

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

Автор:  Vlad [ Вторник, 31 Январь, 2006 03:18 ]
Заголовок сообщения: 

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


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

Автор:  Алексей Елин [ Вторник, 31 Январь, 2006 19:11 ]
Заголовок сообщения: 

Цитата:
Но вот как на уровне гипотетического синтаксиса избавиться от понятия маршаллинга и цикла выборки сообщений - я сейчас не очень представляю.

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

Автор:  Сергей Оборотов [ Вторник, 31 Январь, 2006 22:28 ]
Заголовок сообщения: 

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

Автор:  Vlad [ Среда, 01 Февраль, 2006 00:49 ]
Заголовок сообщения: 

Алексей Елин писал(а):
А вот цикл выбора сообщений - конкретная рализация механизма передачи сообщений (в частности с использованием механизма маршаллинга). И сиснтаксис может "изолировать" пользователя от самого этого цикла. Самый простой пример - message методы в дельфе.


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

Алексей Елин писал(а):
Более сложный: механизм Channels в исследовательской разработке Microsoft - OS Singularity (где для обеспечения устойчивости как раз и запрещается обмениваться указателями между потоками).


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

Автор:  Сергей Оборотов [ Среда, 01 Февраль, 2006 06:39 ]
Заголовок сообщения: 

Vlad писал(а):
Алексей Елин писал(а):
А вот цикл выбора сообщений - конкретная рализация механизма передачи сообщений (в частности с использованием механизма маршаллинга). И сиснтаксис может "изолировать" пользователя от самого этого цикла. Самый простой пример - message методы в дельфе.


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

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

Автор:  Vlad [ Среда, 01 Февраль, 2006 06:56 ]
Заголовок сообщения: 

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


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

Автор:  Сергей Оборотов [ Среда, 01 Февраль, 2006 18:36 ]
Заголовок сообщения: 

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

Автор:  Vlad [ Четверг, 02 Февраль, 2006 03:44 ]
Заголовок сообщения: 

GUEST писал(а):
Есть задачи в которых приемлемо использовать событийно-ориентированную модель.


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

GUEST писал(а):
Может быть вы знаете, что Алексей под пойнерами имел в виду? Глупый вопрос?


Поинтеры? ;)

Автор:  Алексей Елин [ Четверг, 02 Февраль, 2006 21:16 ]
Заголовок сообщения: 

Цитата:
Алексей, а кто такие эти пойнеры?

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

Цитата:
...можно ли увидеть код запускающий какой-нибудь служебный поток. В своем контексте, но с изоляцией от основного потока

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

Автор:  Алексей Елин [ Четверг, 02 Февраль, 2006 21:43 ]
Заголовок сообщения: 

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

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

Цитата:
Цитата:
Более сложный: механизм Channels в исследовательской разработке Microsoft - OS Singularity

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

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

Автор:  Сергей Оборотов [ Четверг, 02 Февраль, 2006 22:24 ]
Заголовок сообщения: 

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

Страница 1 из 5 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/