OberonCore
https://forum.oberoncore.ru/

Многопоточность и сборщик мусора
https://forum.oberoncore.ru/viewtopic.php?f=86&t=6253		 Страница 2 из 2
Автор:  Rifat [ Четверг, 07 Июнь, 2018 09:45 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Madzi писал(а):
Общая память будет в любом случае (не по данным, а по коду), если потоки будут выполняться на одной машине, даже если потоки не будут иметь общих объектов.

Недавно только подумал про эту проблему. Действительно, допустим, есть два потока. Они не имеют общих переменных и общаются только посылкой сообщений. Но, допустим, они могут вызывать какой-нибудь Log.String для вывода сообщений.
И тут возможны следующие варианты:
1) Если ничего не делать, то функция Log.String может быть одновременно вызвана двумя потоками и может произойти ошибка в худшем случае или просто выводимые сообщения "смешаются" друг с другом, а не будут идти друг за другом.
2) Как вариант, вызов Log.String можно вывести в отдельный поток (не обязательно физический поток, это может быть "легкий" поток) и посылать ему сообщение, когда нужно что-то вывести. Тогда два потока не смогут ему послать одновременно два сообщения (или как минимум эти сообщения не будут обрабатываться одновременно) и не будет ошибок, как в пункте 1.
3) Можно оставить два потока, которые общаются сообщениями, а вызовы всех сторонних модулей рассматривать как критическую секцию, в которую нельзя войти одновременно.
Автор:  Илья Ермаков [ Среда, 13 Июнь, 2018 17:58 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Comdiv писал(а):
Илья Ермаков писал(а):
Кроме изолированных по памяти потоков (можно в общем адресном пространстве - например, несколько ББ в одном процессе, что позволяет никогда не пересечься по указателям, но иметь спокойно общие массивы чего-нибудь, например, для вычислительной обработки или быстрого обмена сообщениями)
Это если рассматривать проблему с точки зрения сложности работы сборщика мусора. Если рассматривать с точки зрения надёжности, то общего адресного пространства, доступного для записи, не должно быть.


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

А вот если заменить вашу фразу так:
"Если рассматривать с точки зрения (--надёжности--) ЗАЩИЩЁННОСТИ, то общего адресного пространства, (--доступного для записи--), не должно быть.",
то согласен.
Языковая защита от вредоносного кода, без аппаратной изоляции - опасная игра с огнём. И Java давно на этом прокололась, и в КП находили тонкие места языка, позволяющие обрушить процесс, и т.п.
Автор:  Rifat [ Среда, 13 Июнь, 2018 18:22 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Вопрос защищенности важен для операционной системы, чтобы один процесс не мог получить доступ к памяти другого процесса.
Если же рассматривать случай многопоточного программирования внутри одного приложения, то там важнее вопрос надежности. Если модель многопоточности предусматривает раздельную память, то языковые средства как-то должны сигнализировать о том, что общая память между какими-то процессами все еще осталась и нужно от нее избавиться.
Автор:  Comdiv [ Среда, 13 Июнь, 2018 23:48 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Илья Ермаков писал(а):
Если у Вас герметичный язык - и объектные пространства (кучи динам. объектов) полностью изолированы, то никак на надёжность общее адресное пространство не влияет. Ну на надёжность уровня разрушения памяти, я имею в виду
(Если человек неправильно напишет логику обработки матрицы несколькими Блэкбоксами - это логическая ошибка).
Это на всё влияет - и на возможность разрушения памяти тоже.

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

Цитата:
А вот если заменить вашу фразу так:
"Если рассматривать с точки зрения (--надёжности--) ЗАЩИЩЁННОСТИ, то общего адресного пространства, (--доступного для записи--), не должно быть.",
то согласен.
Под надёжностью я понимаю ошибкоустойчивость вообще, в том числе от логических ошибок. Последствия от них могут быть ничуть не хуже, чем от других ошибок. Для защищённости, как возможности противостояния злому умыслу, с одной стороны, ошибкоустойчивость полезна, с другой - далеко не всегда критична в зависимости от типа совершаемых действий.
Автор:  Comdiv [ Четверг, 14 Июнь, 2018 14:39 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Цитата:
Если индекс по каким-либо причинам доступен для записи второму потоку, то при выполнении такого кода можно добиться проверки одного - корректного значения, а записи по другому - некорректному. Это не так просто, как портить память без проверки, тем не менее подобные ошибки успешно используются для создания уязвимостей, не говоря про появление обычных ошибок нарушения памяти.
Это, конечно же, лечится, но этим нужно заниматься изначально с расчётом на многопоточность, которая, как известно, противоречит описанию языка.
Код:
j := i;
ASSERT((0 <= j) & (j < LEN(a)));
a[j] := val;
Автор:  Илья Ермаков [ Пятница, 15 Июнь, 2018 12:18 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
А я считаю, что надо чётко разделять ошибки разрушения целостности памяти и логические ошибки повреждения состояния данных.

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

Моя позиция такова:
1) Архитектурно-технические решения должны не допускать разрушения целостности памяти.
2) Применять общие данные (без указателей) вполне допустимо в рамках вычислительных алгоритмов или алгоритмов производительного обмена данными.
Риски логических ошибок совместной обработки данных несколькими потоками, конечно, есть.
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.
Автор:  Comdiv [ Пятница, 15 Июнь, 2018 14:40 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Илья Ермаков писал(а):
А я считаю, что надо чётко разделять ошибки разрушения целостности памяти и логические ошибки повреждения состояния данных.

Вы привели пример со вторым.
Я писал о первом. Возможно, в заблуждение ввело использование Оберона вместо машинного языка. Надо, конечно, смотреть как конкретно транслируется код, но в С++ такая порча была возможна несмотря на использование проверки без участия программиста. Для этого даже не требовалась параллельность, достаточно было заковыристого выражения.
Автор:  Rifat [ Пятница, 15 Июнь, 2018 21:42 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Илья Ермаков писал(а):
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.

Deadlock-и не так страшны, как их описывают. Можно, например, легко перевести ситуацию deadlock к вызову assert, а можно даже assert не вызывать, а просто завершать параллельное выполнение, если произошёл deadlock.
Автор:  Илья Ермаков [ Суббота, 16 Июнь, 2018 12:09 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Rifat писал(а):
Илья Ермаков писал(а):
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.

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


А Вам ещё надо сложный анализ графа взаимных ожиданий делать. Чтобы развязывать этот дидлок.
Модель туевой кучи физически параллельных объектов, друг друга вызывающих - это полный пипец.
Автор:  prospero78 [ Четверг, 25 Октябрь, 2018 19:09 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Rifat писал(а):
1) Если ничего не делать, то функция Log.String может быть одновременно вызвана двумя потоками и может произойти ошибка в худшем случае или просто выводимые сообщения "смешаются" друг с другом, а не будут идти друг за другом.

Это вряд ли. Сообщение -- это одна единица информации. Потоки добавляют в общую очередь сообщения, которые по факту добавления активируют счётчик вывода в выходной поток (если есть такой объект агрегации по отношению ко всем потокам). Если механизм исполнения не предполагает обрыв исполнения по счётчику исполненных инструкций (как GIL в python, например) -- тогда таких проблем не будет.

Цитата:
2) Как вариант, вызов Log.String можно вывести в отдельный поток (не обязательно физический поток, это может быть "легкий" поток) и посылать ему сообщение, когда нужно что-то вывести. Тогда два потока не смогут ему послать одновременно два сообщения (или как минимум эти сообщения не будут обрабатываться одновременно) и не будет ошибок, как в пункте 1.

Да. Задача решена.

Цитата:
3) Можно оставить два потока, которые общаются сообщениями, а вызовы всех сторонних модулей рассматривать как критическую секцию, в которую нельзя войти одновременно.

Это медленно. И самое главное: страшен не одновременный вход. Страшен одновременный вывод. Поэтому очередь.
Автор:  Rifat [ Пятница, 26 Октябрь, 2018 06:51 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Илья Ермаков писал(а):
Rifat писал(а):
Илья Ермаков писал(а):
Но это не риски многопоточности в едином пространстве объектов, где любая вложенная цепочка вызовов методов потенциально грозит deadlock-ом.

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


А Вам ещё надо сложный анализ графа взаимных ожиданий делать. Чтобы развязывать этот дидлок.
Модель туевой кучи физически параллельных объектов, друг друга вызывающих - это полный пипец.
Автор:  budden [ Вторник, 30 Октябрь, 2018 13:02 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Rifat писал(а):
вызов Log.String можно вывести в отдельный поток (не обязательно физический поток, это может быть "легкий" поток) и посылать ему сообщение, когда нужно что-то вывести.


Код:
Log.String("Привет, Вася!);
Log.Ln;
Log.String("Как ты поживаешь?");
Автор:  prospero78 [ Среда, 31 Октябрь, 2018 18:52 ]
Заголовок сообщения:  Re: Многопоточность и сборщик мусора
Цитата:
вызов Log.String можно вывести в отдельный поток (не обязательно физический поток, это может быть "легкий" поток) и посылать ему сообщение, когда нужно что-то вывести.

Поток в любом случае:
1) Физический
2) Имеет источник и приёмник))
Страница 2 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/