OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 24 Сентябрь, 2018 13:05

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




Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Четверг, 07 Июнь, 2018 09:45 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 696
Откуда: Казань
Madzi писал(а):
Общая память будет в любом случае (не по данным, а по коду), если потоки будут выполняться на одной машине, даже если потоки не будут иметь общих объектов.

Недавно только подумал про эту проблему. Действительно, допустим, есть два потока. Они не имеют общих переменных и общаются только посылкой сообщений. Но, допустим, они могут вызывать какой-нибудь Log.String для вывода сообщений.
И тут возможны следующие варианты:
1) Если ничего не делать, то функция Log.String может быть одновременно вызвана двумя потоками и может произойти ошибка в худшем случае или просто выводимые сообщения "смешаются" друг с другом, а не будут идти друг за другом.
2) Как вариант, вызов Log.String можно вывести в отдельный поток (не обязательно физический поток, это может быть "легкий" поток) и посылать ему сообщение, когда нужно что-то вывести. Тогда два потока не смогут ему послать одновременно два сообщения (или как минимум эти сообщения не будут обрабатываться одновременно) и не будет ошибок, как в пункте 1.
3) Можно оставить два потока, которые общаются сообщениями, а вызовы всех сторонних модулей рассматривать как критическую секцию, в которую нельзя войти одновременно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Июнь, 2018 17:58 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Comdiv писал(а):
Илья Ермаков писал(а):
Кроме изолированных по памяти потоков (можно в общем адресном пространстве - например, несколько ББ в одном процессе, что позволяет никогда не пересечься по указателям, но иметь спокойно общие массивы чего-нибудь, например, для вычислительной обработки или быстрого обмена сообщениями)
Это если рассматривать проблему с точки зрения сложности работы сборщика мусора. Если рассматривать с точки зрения надёжности, то общего адресного пространства, доступного для записи, не должно быть.


Если у Вас герметичный язык - и объектные пространства (кучи динам. объектов) полностью изолированы, то никак на надёжность общее адресное пространство не влияет. Ну на надёжность уровня разрушения памяти, я имею в виду (Если человек неправильно напишет логику обработки матрицы несколькими Блэкбоксами - это логическая ошибка).

А вот если заменить вашу фразу так:
"Если рассматривать с точки зрения (--надёжности--) ЗАЩИЩЁННОСТИ, то общего адресного пространства, (--доступного для записи--), не должно быть.",
то согласен.
Языковая защита от вредоносного кода, без аппаратной изоляции - опасная игра с огнём. И Java давно на этом прокололась, и в КП находили тонкие места языка, позволяющие обрушить процесс, и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Июнь, 2018 18:22 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 696
Откуда: Казань
Вопрос защищенности важен для операционной системы, чтобы один процесс не мог получить доступ к памяти другого процесса.
Если же рассматривать случай многопоточного программирования внутри одного приложения, то там важнее вопрос надежности. Если модель многопоточности предусматривает раздельную память, то языковые средства как-то должны сигнализировать о том, что общая память между какими-то процессами все еще осталась и нужно от нее избавиться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Июнь, 2018 23:48 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Илья Ермаков писал(а):
Если у Вас герметичный язык - и объектные пространства (кучи динам. объектов) полностью изолированы, то никак на надёжность общее адресное пространство не влияет. Ну на надёжность уровня разрушения памяти, я имею в виду
(Если человек неправильно напишет логику обработки матрицы несколькими Блэкбоксами - это логическая ошибка).
Это на всё влияет - и на возможность разрушения памяти тоже.

Простая защита от порчи памяти обеспечивается приблизительно так:
Код:
ASSERT((0 <= i) & (i < LEN(a)));
a[i] := val;
Если индекс по каким-либо причинам доступен для записи второму потоку, то при выполнении такого кода можно добиться проверки одного - корректного значения, а записи по другому - некорректному. Это не так просто, как портить память без проверки, тем не менее подобные ошибки успешно используются для создания уязвимостей, не говоря про появление обычных ошибок нарушения памяти.

Цитата:
А вот если заменить вашу фразу так:
"Если рассматривать с точки зрения (--надёжности--) ЗАЩИЩЁННОСТИ, то общего адресного пространства, (--доступного для записи--), не должно быть.",
то согласен.
Под надёжностью я понимаю ошибкоустойчивость вообще, в том числе от логических ошибок. Последствия от них могут быть ничуть не хуже, чем от других ошибок. Для защищённости, как возможности противостояния злому умыслу, с одной стороны, ошибкоустойчивость полезна, с другой - далеко не всегда критична в зависимости от типа совершаемых действий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 14 Июнь, 2018 14:39 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Цитата:
Если индекс по каким-либо причинам доступен для записи второму потоку, то при выполнении такого кода можно добиться проверки одного - корректного значения, а записи по другому - некорректному. Это не так просто, как портить память без проверки, тем не менее подобные ошибки успешно используются для создания уязвимостей, не говоря про появление обычных ошибок нарушения памяти.
Это, конечно же, лечится, но этим нужно заниматься изначально с расчётом на многопоточность, которая, как известно, противоречит описанию языка.
Код:
j := i;
ASSERT((0 <= j) & (j < LEN(a)));
a[j] := val;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Июнь, 2018 12:18 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
А я считаю, что надо чётко разделять ошибки разрушения целостности памяти и логические ошибки повреждения состояния данных.

Вы привели пример со вторым.

Моя позиция такова:
1) Архитектурно-технические решения должны не допускать разрушения целостности памяти.
2) Применять общие данные (без указателей) вполне допустимо в рамках вычислительных алгоритмов или алгоритмов производительного обмена данными.
Риски логических ошибок совместной обработки данных несколькими потоками, конечно, есть.
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Июнь, 2018 14:40 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Илья Ермаков писал(а):
А я считаю, что надо чётко разделять ошибки разрушения целостности памяти и логические ошибки повреждения состояния данных.

Вы привели пример со вторым.
Я писал о первом. Возможно, в заблуждение ввело использование Оберона вместо машинного языка. Надо, конечно, смотреть как конкретно транслируется код, но в С++ такая порча была возможна несмотря на использование проверки без участия программиста. Для этого даже не требовалась параллельность, достаточно было заковыристого выражения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Июнь, 2018 21:42 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 696
Откуда: Казань
Илья Ермаков писал(а):
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.

Deadlock-и не так страшны, как их описывают. Можно, например, легко перевести ситуацию deadlock к вызову assert, а можно даже assert не вызывать, а просто завершать параллельное выполнение, если произошёл deadlock.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 16 Июнь, 2018 12:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Rifat писал(а):
Илья Ермаков писал(а):
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.

Deadlock-и не так страшны, как их описывают. Можно, например, легко перевести ситуацию deadlock к вызову assert, а можно даже assert не вызывать, а просто завершать параллельное выполнение, если произошёл deadlock.


А Вам ещё надо сложный анализ графа взаимных ожиданий делать. Чтобы развязывать этот дидлок.
Модель туевой кучи физически параллельных объектов, друг друга вызывающих - это полный пипец.


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

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


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

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


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

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