OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 13 Декабрь, 2019 15:55

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 28 Январь, 2006 00:29 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
А возможно ли "заставить" GC в BB выделять и собирать память в каждом потоке по отдельности (+вожможность передавать объекты между потоками).
Т.е. в каком потоке память выделена, в таком и проверяются на нее ссылки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 28 Январь, 2006 03:53 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Цитата:
А возможно ли "заставить" GC в BB выделять и собирать память в каждом потоке по отдельности (+вожможность передавать объекты между потоками).
Т.е. в каком потоке память выделена, в таком и проверяются на нее ссылки.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 29 Январь, 2006 21:46 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
Цитата:
А вот выделение для каждого потока по отдельности не только не имеет смысла, но и вообще не позволительно: вся безопасность летит к... А если ссылка ушла из стека потока куда-нибудь еще?


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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 29 Январь, 2006 23:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Тогда идею почти понял. Интересная идея. Однако запретить передачу ссылок между потоками напрямую сложно. Точнее, на уровне синтаксиса КП вообще невозможно. А "джентльменское соглашение" - слишком эфемерная штука и как раз не в стиле Оберона.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Понедельник, 30 Январь, 2006 00:42 

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

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Понедельник, 30 Январь, 2006 07:23 

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Понедельник, 30 Январь, 2006 23:05 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
Цитата:
Прелесть потоков как раз в общем разделяемом адресном пространстве. И это их основное отличие от процессов.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Понедельник, 30 Январь, 2006 23:43 

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


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 31 Январь, 2006 00:16 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
Цитата:
Работу через механизм передачи сообщений можно наблюдать в COM для случая MTA.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 31 Январь, 2006 03:18 

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 31 Январь, 2006 19:11 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
Цитата:
Но вот как на уровне гипотетического синтаксиса избавиться от понятия маршаллинга и цикла выборки сообщений - я сейчас не очень представляю.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 31 Январь, 2006 22:28 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Алексей, а кто такие эти пойнеры? Касательно Вашего предложения - можно ли увидеть код запускающий какой-нибудь служебный поток. В своем контексте, но с изоляцией от основного потока. Кстати, если основной поток закрыть - он закроется?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 01 Февраль, 2006 00:49 

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


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 01 Февраль, 2006 06:39 

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


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 01 Февраль, 2006 06:56 

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 01 Февраль, 2006 18:36 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Пока о системе речь не шла вроде. Да и не спорить моя задача, понимаешь. Есть задачи в которых приемлемо использовать событийно-ориентированную модель. Вот моя задача и состоит в том, чтобы разобраться как её эффективнее реализовать. Может быть вы знаете, что Алексей под пойнерами имел в виду? Глупый вопрос?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 02 Февраль, 2006 03:44 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
GUEST писал(а):
Есть задачи в которых приемлемо использовать событийно-ориентированную модель.


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

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


Поинтеры? ;)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 02 Февраль, 2006 21:16 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
Цитата:
Алексей, а кто такие эти пойнеры?

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 02 Февраль, 2006 21:43 

Зарегистрирован: Суббота, 28 Январь, 2006 00:10
Сообщения: 52
Откуда: г. Киров
Цитата:
Ну вот лично я сходу такой простой практический пример не придумаю (негуевый поток с событийным управлением).

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 02 Февраль, 2006 22:24 

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу 1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB