Здравствуйте, Pavel Dvorkin, Вы писали:
M>>И вообще, если два процесса разделяют общие данные, то это уже не два процесса, а два потока одного процесса.
PD>Поаккуратнее с терминологией, пожалуйста. Так недалеко и до полного абсурда дойти. Разделять-то они разделяют, но каждый их имеет отдельно в своем адресном пространстве
Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками. Как раз потому что адресное пространство у процессов разное, по любому придется думать о валидности указателей в обоих процессах: либо использовать смещения, либо хаки вроде __based, либо какой-то аналогичный велосипед.
ЗЫ
Кстати, тут можно маленько пофантазировать. Если процесс это некая сущность объединяющая 1 адресное и N потоков, то вполне можно представить себе некоторую матрицу в которой в столбцах — потоки, в строках — адресные пространства (АП), а в ячейках — аксессоры для синхронизации доступа потоков к АП. Потоки работают с АП через аксессоры и напрямую работают с thread local storages. При должной языковой поддержке может получится вполне удобная и понятная модель для многопоточного программирования на shared-memory системах. Если язык сможет в compiletime и в runtime бить по рукам за попытки сравнивать/присваивать указатели из разных АП как за нарушение типизации, а так же бить за попытку разрезолвить указатель одного АП в другом, то может весьма красиво получиться.
M>Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками.
Тогда уж один job с двумя процессами
>Как раз потому что адресное пространство у процессов разное, по любому придется думать о валидности указателей в обоих процессах: либо использовать смещения, либо хаки вроде __based
Опять же поосторожней с терминами. Это не хак, а вполне документированная фича.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками.
PD>Тогда уж один job с двумя процессами
Ээээээ.... . Вы меня таки уличили в незнании терминов. Как я понимаю процесс == task == N потоков + данные, поток == thread. Что такое job?
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>>Я хочу сказать, что если есть надобность так разделять данные, то логично было бы сделать один процесс с двумя потоками.
PD>>Тогда уж один job с двумя процессами :-)
M>Ээээээ.... . Вы меня таки уличили в незнании терминов. Как я понимаю процесс == task == N потоков + данные, поток == thread. Что такое job?
Ну для начала task != process, task это единица шедулинга (внутри процесса task есть thread, но могут быть и чисто ядерные задачи без процессов). По крайней мере в наших краях только так.
Ну а по смыслу тут понятно, что job тут — это "самодельное" явление из двух процессов (по контексту — с частично общей памятью).
S>> Ну один процесс свалился, куда ссылки будут указывать? WH>Куда указывали туда и будут. WH>В чем вообще проблема? WH>Что думаешь сборщик мусора написать не получится?
Все возможно, но пока например то, что существует хорошо описал : eao197 http://rsdn.ru/forum/cpp.applied/3147301.1.aspx
S>> При копировании таких проблем нет. WH>За то есть много других. WH>Например отжер памяти и тормоза.
Но есть однозначность данных, которых не будет при падение процесса.
Кстати эо вопрос о внутренних и внешних серверах, если тебе нужен интенсивныйобмен данными, то либо
старайся всю обработку выполнять на сервере, получая лаконичные результаты.
А так я двумя руками за твое предложение, осталось его еще реализовать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Mazay, Вы писали:
M>Ээээээ.... . Вы меня таки уличили в незнании терминов. Как я понимаю процесс == task == N потоков + данные,
Термин task присутствовал в Win16 и был официально исключен MS при переходе к Win32. В остальном верно.
>поток == thread.
Да
>Что такое job?
A job object allows groups of processes to be managed as a unit. Job objects are namable, securable, sharable objects that control attributes of the processes associated with them. Operations performed on the job object affect all processes associated with the job object.
Здравствуйте, netch80, Вы писали:
N>Ну для начала task != process, task это единица шедулинга (внутри процесса task есть thread, но могут быть и чисто ядерные задачи без процессов). По крайней мере в наших краях только так.
N>Ну а по смыслу тут понятно, что job тут — это "самодельное" явление из двух процессов (по контексту — с частично общей памятью).
Не знаю, что есть ваши края, но если речь идет о Windows, то все неверно. Нет там task, нет ядерных задач без процессов (любой поток выполняется в каком-то процессе), job не есть самодельное явление, а объект ядра , ну а общая память у двух процессов возможна как в случае, когда они входят в job, так и если не входят.
Здравствуйте, Serginio1, Вы писали:
WH>>Что думаешь сборщик мусора написать не получится? S>Все возможно, но пока например то, что существует хорошо описал : eao197 S>http://rsdn.ru/forum/cpp.applied/3147301.1.aspx
И чего он там описал?
Ерланг? Так ерланг как раз шарит неизменяемые данные между процессами.
Свою библиотеку на С++? Так она вообще к делу не относится.
Если ты про данные которые идут на другую машину то тот уже не IPC, а RPC...
S> Но есть однозначность данных, которых не будет при падение процесса.
Чё?
S>Кстати эо вопрос о внутренних и внешних серверах, если тебе нужен интенсивныйобмен данными, то либо S>старайся всю обработку выполнять на сервере, получая лаконичные результаты.
Какие еще серверы?
Что ты вот с таким сценарием делать будешь? http://rsdn.ru/forum/philosophy/3437966.1.aspx
Здравствуйте, WolfHound, Вы писали:
WH>Ерланг? Так ерланг как раз шарит неизменяемые данные между процессами.
Нт про
Множество мелких процессов и обмен сообщениями -- это средство для обеспечения оказоустойчивости. Падение процесса -- это всего лишь падение одного процесса. Shit happens и с этим нужно считаться. Erlang считается с этим посредством мелких процессов, не имеющих разделяемых данных между собой. Обмен сообщениями -- это необходимая (при этом простая и, одновременно, мощная) форма взаимодействия процессов.
S>> Но есть однозначность данных, которых не будет при падение процесса. WH>Чё?
На что ссылаться будут данные при падении процесса? S>>Кстати эо вопрос о внутренних и внешних серверах, если тебе нужен интенсивныйобмен данными, то либо S>>старайся всю обработку выполнять на сервере, получая лаконичные результаты. WH>Какие еще серверы?
COM,SQL и прочие, то что можно разделить на выполнение в одном процессе и другом так назовем домене. WH>Что ты вот с таким сценарием делать будешь? WH>http://rsdn.ru/forum/philosophy/3437966.1.aspx
Не силен в драйверах, но то что мои скудные познания дают приблизительно это.
SQL хранит данные страницами так же как и ОС, только вот внутри физически странца имеет доп данные.
Наверное нужны драйвера которые вместо данных в странице будут брать из переданных данных.
Если же болб лежит в последовательных страницах то и выдумывать особо нечего.
Кстати здесь уже Mystic прелагал обмен на файлах в памяти
S>> А так я двумя руками за твое предложение, осталось его еще реализовать. WH>Дело техники и некоторого количества бабла.
Мои возможности весьма скромны и ограничены
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
WH>>Ерланг? Так ерланг как раз шарит неизменяемые данные между процессами. S>Нт про S>
S>Множество мелких процессов и обмен сообщениями -- это средство для обеспечения оказоустойчивости. Падение процесса -- это всего лишь падение одного процесса. Shit happens и с этим нужно считаться. Erlang считается с этим посредством мелких процессов, не имеющих разделяемых данных между собой. Обмен сообщениями -- это необходимая (при этом простая и, одновременно, мощная) форма взаимодействия процессов.
Еще раз для особо одаренных: Ерланг шарит данные между процессами. Но так как данные неизменяемые это не создает проблем.
S>>> Но есть однозначность данных, которых не будет при падение процесса. WH>>Чё? S> На что ссылаться будут данные при падении процесса?
Блин. На данные. На что же еще?
S> COM,SQL и прочие, то что можно разделить на выполнение в одном процессе и другом так назовем домене.
Еще раз читай ссылку.
S>Не силен в драйверах, но то что мои скудные познания дают приблизительно это.
Во-во.
S> SQL хранит данные страницами так же как и ОС, только вот внутри физически странца имеет доп данные. S>Наверное нужны драйвера которые вместо данных в странице будут брать из переданных данных.
Ахринеть дайте две.
S> Если же болб лежит в последовательных страницах то и выдумывать особо нечего.
Кроме одной мелочи: Как сказать драйверу сетевухи чтобы он прочитал с винта эти страницы.
Я описал как это сделать так чтобы не появилось лишних зависимостей.
S>Кстати здесь уже Mystic прелагал обмен на файлах в памяти
И причем тут правильные ОС?
S> Мои возможности весьма скромны и ограничены
Надеюсь что ты не думаешь что у всех возможности столь скромны и ограничены?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Ну для начала task != process, task это единица шедулинга (внутри процесса task есть thread, но могут быть и чисто ядерные задачи без процессов). По крайней мере в наших краях только так. N>>Ну а по смыслу тут понятно, что job тут — это "самодельное" явление из двух процессов (по контексту — с частично общей памятью). PD>Не знаю, что есть ваши края, но если речь идет о Windows, то все неверно.
Нет, о Unix. Контекст Windows нигде ещё в данной теме не фиксировался. А если Вы "не знаете, что есть ваши края", то зачем минус ставите? Просто так?
Тогда сорри.
>А если Вы "не знаете, что есть ваши края", то зачем минус ставите? Просто так?
Убрал. Просто, мне казалось, что из моих сообщений ясно, что я говорю о Windows. Видимо, это не так. Но и тебе стоило просто указать, что речь идет о Unix, вместо того, чтобы ссылаться на туманные края
Здравствуйте, WolfHound, Вы писали: WH>Еще раз для особо одаренных: Ерланг шарит данные между процессами. Но так как данные неизменяемые это не создает проблем.
Если процесс упал, то ссылки на данные могут быть неправильными, т.к. могут содержать данные на закрытые ресурсы.
Т.к. закрытие процесса, гарантирует закрытие ресурсов.
Если это не так, то какой смысл в процессах? Пусть все выпоняется в потоках.
Ну да ладно здесь я сильно некопенгаген.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Если процесс упал, то ссылки на данные могут быть неправильными,
Не могут.
S>т.к. могут содержать данные на закрытые ресурсы.
Каждое слово по отдельности понятно но вот вместе
S>Т.к. закрытие процесса, гарантирует закрытие ресурсов.
Каких еще ресурсов?
Нет никаких ресурсов.
Есть только каналы типа тех что в сингулярити.
Какие проблемы с каналами?
S> Если это не так, то какой смысл в процессах? Пусть все выпоняется в потоках.
Для изоляции.
S> Ну да ладно здесь я сильно некопенгаген.
Это точно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
S>>Т.к. закрытие процесса, гарантирует закрытие ресурсов. WH>Каких еще ресурсов? WH>Нет никаких ресурсов. WH>Есть только каналы типа тех что в сингулярити. WH>Какие проблемы с каналами?
Т.к. некопенгаген задам вопрос для большего понимания проблемы.
Разговор шел об общей памяти между процессами.
Каналы предлагают Exchange Heap, но это немного другое.
См выделенное.
4.5 Владение
Для гарантии изоляции памяти конечных точек и других данных, передаваемых по каналу, все блоки в Exchange Heap являются ресурсами, которые нужно отслеживать при компиляции. В частности, статические проверки обеспечивают, что доступ к этим ресурсам производится только в точках программы, где она владеет ресурсом, и методами, не нарушающими владение ресурсами. Существует строгая модель владения отслеживаемыми ресурсами. Каждым ресурсом в любой момент времени может владеть не более одного потока (или структуры данных в потоке). Например, если конечная точка передается в сообщении от потока Т1 потоку Т2, ее собственник меняется: от Т1 она переходит к сообщению, а затем, после получения сообщения, к Т2.
Для упрощения статического отслеживания ресурсов указатели на ресурсы могут содержаться только в статических переменных, сообщениях и структурах данных, которые сами отслеживаются. Эти ограничения иногда могут быть обременительными. Поэтому Sing# предоставляет возможность обойти их, сохраняя отслеживаемые ресурсы косвенно, внутри структур данных, через абстракцию TRef.
4.6 TRef
TRef – это ячейка хранения типа TRef<T>, содержащая отслеживаемую структуру данных типа Т. Сигнатура TRef такова:
class TRef<T> where T: ITracked
{
public TRef([Claims] T i_obj);
public T Acquire();
public void Release([Claims] T newObj);
}
При создании TRef<T> конструктор требует в качестве аргумента объект типа Т. Вызывающая сторона должна владеть объектом на стороне создания. После создания владение передается созданному TRef. Для получения содержимого TRef используется метод Acquire. Если TRef заполнен, он возвращает свое содержимое и передает владение стороне, вызвавшей Acquire. После этого TRef считается пустым. Release передает владение объектом T от вызывающей стороны TRef-у. После этого TRef является заполненным. TRef-ы потокобезопасны. Операция Acquire блокируется, пока TRef заполнен.
TRef – это компромисс между статическими и динамическими проверками. При использовании TRef множественные некорректные запросы превращаются во взаимоблокировки, и освобождением ресурса занимается механизм финализации сборщика мусора.
4.7 Exchange Heap
Поскольку владение блоками памяти передается при обмене сообщениями от одного потока или процесса другому, Singularity необходим способ выделения и отслеживания таких блоков. Система каналов требует, чтобы параметры сообщения были или скалярами, или блоками в Exchange Heap. Есть два вида блоков Exchange Heap: индивидуальные блоки и векторы. Их типы записываются, соответственно, так:
using Microsoft.Singularity.Channels;
R* in ExHeap pr;
R[] in ExHeap pv;
ПРИМЕЧАНИЕ
Конечные точки в Exchange heap представлены как отдельные блоки.
Тип указателя pr говорит, что он указывает на структуру R в Exchange Heap. ExHeap – это тип, определенный исполняющей системой, обеспечивающей выделение, освобождение и другую поддержку данной кучи. Тип pv – это вектор R в Exchange Heap.
Инвариант Exchange Heap в том, что она не содержит никаких указателей на GC-кучу какого либо процесса. Таким образом, тип R должен быть обмениваемым типом, то есть примитивным value-типом (int, char и т.д.), перечислением или простой структурой с полями обмениваемых типов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Т.к. некопенгаген задам вопрос для большего понимания проблемы. S> Разговор шел об общей памяти между процессами. S>Каналы предлагают Exchange Heap, но это немного другое.
Если ты не понимаешь что сингулярити лишь одна из возможных реализаций и что в другой реализации каналы могут иметь иные ограничения то я тебе ничем не могу помочь.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
S>>Т.к. некопенгаген задам вопрос для большего понимания проблемы. S>> Разговор шел об общей памяти между процессами. S>>Каналы предлагают Exchange Heap, но это немного другое. WH>Если ты не понимаешь что сингулярити лишь одна из возможных реализаций и что в другой реализации каналы могут иметь иные ограничения то я тебе ничем не могу помочь.
Зачем тогда ссылался на сингулярити. Мне честно интересен сам механизм, иначе бы и не впрягался в этоту беседу.
Что касается объектов не содержащих ресурсов и имутабельных, вполне возможно держать их в единой куче, а что содержит ресурсы и изменяемые,то типа TRef, или
сериализация ремотинг.
При выгрузке процесса, нужно будет подчистить за собой освободив ресурсы.
Сейчас по аналогии с доменом, ресурсы закрываются, память высвобождается. Все просто.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Нельзя передавать указатели на свою память, это нарушит изоляцию процессов. Указатели на разделяемую память — сколько угодно.
PD>Категорически нет. Адреса разделяемой памяти в разных процессах различны, по крайней мере в Windows линии NT. Вот в 9x можно
Речь же идёт о некоей гипотетической ОС, которая сама вся из себя верифицируемая. Как эту ОС напишешь — так и будет.
Здравствуйте, Serginio1, Вы писали:
S> Зачем тогда ссылался на сингулярити.
За тем что каналы из сингулярити отличный примитив для общения между процессами.
S> Мне честно интересен сам механизм, иначе бы и не впрягался в этоту беседу.
Механизм чего? Того как сборщик мусора на неизменяемой кучи работает? Так это долго рассказывать.
Или общения между процессами? Тут все очень просто. Повторю еще раз: Просто передаем ссылку на неизменяемый объект в другой процесс и все. Дальше разберется сборщик мусора.
S>Что касается объектов не содержащих ресурсов и имутабельных, вполне возможно держать их в единой куче, а что содержит ресурсы и изменяемые,то типа TRef, или сериализация ремотинг.
Тут вообще каша. Ничего не понял.
С тобой очень трудно разговаривать.
Выражайся яснее.
S>При выгрузке процесса, нужно будет подчистить за собой освободив ресурсы.
Какие еще ресурсы?
Выражайся яснее.
S>Сейчас по аналогии с доменом, ресурсы закрываются, память высвобождается. Все просто.
И тут все просто. Каналы закрываются. Кучи связанные с процессом тоже просто освобождаются.
А с разделяемыми данными разберутся потом.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>>Что касается объектов не содержащих ресурсов и имутабельных, вполне возможно держать их в единой куче, а что содержит ресурсы и изменяемые,то типа TRef, или сериализация ремотинг. WH>Тут вообще каша. Ничего не понял. WH>С тобой очень трудно разговаривать. WH>Выражайся яснее.
Для имутабельных про S>>При выгрузке процесса, нужно будет подчистить за собой освободив ресурсы. WH>Какие еще ресурсы? WH>Выражайся яснее.
Ресурсы это Файлы, каналы, итд. что при выгрузки процесса должно закрыться, а значит не должно иметь прямых ссылок из других процессов.
А также мутабельные объекты должны храниться в куче процесса.
S>>Сейчас по аналогии с доменом, ресурсы закрываются, память высвобождается. Все просто. WH>И тут все просто. Каналы закрываются. Кучи связанные с процессом тоже просто освобождаются. WH>А с разделяемыми данными разберутся потом.
Только кучи должны быть разными для разделяемых и неразделяемых объетов.
Ладно приблизительно понял, Спасибо.
и солнце б утром не вставало, когда бы не было меня
