OberonCore

(модератор) выделено из темы viewtopic.php?p=82087#p82087 согл. п. 3.3


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

Слушай, ну а как же Redis, Tarantool и ряд других NoSQL прекрасно живут на одном потоке? И имеют фантастическую пропускную способность. Именно из-за отказа от блокировок и конкурентности...
А загрузить все ядра можно и группой процессов. Если же хотим распределяться - то проще использовать один механизм (изолированные процессы), чем какие-то заморочки с общей памятью.

Хорошо бы в этой теме найти систематические основания какие-то.
Какую-нибудь опорную теорему, что ли, как, типа, с GOTO.

Один поток будет тормозить весь сервер, если он будет блокироваться на вводе-выводе (жёсткий диск, сеть, IPC, другие устройства).

Множество потоков (сверх 20-30) будут тормозить сервер из-за своей природы (накладные расходы напереключение, издержки синхронизации). Пару лет назад проверял с коллегами работу нашего сервера, если там на каждую задачу по потоку. Потоков оказалось больше 2000, а один только запуск сервера требовал минут пять.

Так что, если существует механизм неблокирующего ввода-вывода, то однопоточное приложение часто будет лучше.

Но здесь ещё есть нюанс с ядрами процессора.

А вы пробовали потоки из А2 ? Там вроде как 50000 потоков без проблем держит. При том, что нет переключения контекстов (т.е. накладных расходов).

Нет, я их не видел. Всё руки не дойдут посмотреть такие потоки, их реализацию. Всё никак не могу понять, почему они есть в отдельных продуктах, но не в ОС, на которой продукты крутятся. ОС в данном случае - винда и линукс.

Но переключение контекстов всё равно есть: банально состояние регистров и стэк у каждого потока свои. И, вроде, самая большая проблема в потоках - общие данные. Решается она не всегда эффективно.

A2 по сути ОС и есть. WinAOS и UnixAOS - лишь прослойки для её запуска поверх другой ОС.
В ней (А2) переключения контекстов нет, так как всё выполняется в одном адресном пространстве (соответственно и проблем с общим доступом к памяти нет, точнее они есть, но решаются через эксклюзивный доступ (директива {EXCLUSIVE})).

Я знаю. Просто, проблемы и решения, касающиеся многопоточности, я встречал в сети только для этих ОС. Поэтому их и упомянул: чтобы не казалось, что сказанное относится и к другим ОС (помимо A2 есть ещё много других: Plan 9, Inferno, Haiku, AROS, RiscOS и т.д.).
Вы, наверно, используете понятие "контекст" в узкоспециализированном смысле. У разных потоков есть уникальные ресурсы. Именно потому потоки и разные. И чтобы при переключении не потерять ресурсы потока, ОС делает некоторые действия, чтобы потом всё корректно восстановить. Допускаю, что в A2 переключение происходит несколько быстрее, но сомневаюсь, что разница большая.

Что же касается совместного доступа к ресурсу в памяти, то только лишь директивой проблему не решить. Если методы синхронизации классические, то и производительность будет примерно на уровне других ОС. Архитектура ОС здесь не важна, важен алгоритм. И если в ETH ничего нового не придумали, то чудес ожидать не стоит.

В Composita у них поддерживались сотни тысяч потоков - за счёт того, что компилятор как-то хитро "сшивает" потоки.

Композита работает поверх A2, используя её "родные" потоки. Фактически это "метапрограммиронивание". Создаются новые сущность поверх существующих.

Вообще, название темы довольно неграмотное. Точнее было бы её назвать - "нужна ли вытесняющая многозадачность?".

Вытесняющая многозадачность например совсем не нужна вот в этом случае:

Просто потому, что никто не отменял неблокирующую, асинхронную, работу с сетью, IPC и так далее. Это есть везде. Поэтому обычному скажем веб-серверу вытесняющая многозадачность нафиг не уперлась.

Но представим что у нас не просто веб-сервер, у нас, скажем, сервер видеоконференций. (и пусть у него, чтобы пример был ярче, всего один процессор с одним ядром, так что многопоточность нам тут скорости не прибавит). Он не просто байтики перекладывает, но над полученными байтиками он производить сложные и длительные математические вычисления (кодирование/декодирование h264/h265, всякие фильтры и так далее). На очередную порцию байтиков может действительно уйти МНОГО времени - до одной секунды (ключевой кадр например). И, что важнее - прервать эту операцию на середине, и передать управление другому коду в случае кооперативной (не вытесняющей) многозадачности просто невозможно (если у нас математический код не спец. компилятором собран, который навтыкает счетчиков да yield'ов, тем самым СИЛЬНО (в 4-10 раз) снизив производительность на современном x86 (из за условных переходов предсказатель переходов начнет ошибаться)). Следовательно вызов такой вот математики - блокирующий. А мы не имеем права уходить в себя на целую секунду - jitter buffer обычно настроен на 200ms максимум, нельзя чтобы другие клиенты страдали. У нас реалтайм. Поэтому в этом классе задач вытесняющая многозадачность нужна.

Теперь вопрос в том - потоки, или процессы? Увы, но множество процессов тоже не годится - объем передаваемых данных велик, поэтому накладные расходы на IPC будут слишком велики (причем как на передачу данных так и на примитивы синхронизации). Плодить по процессу на каждую конференцию или на каждого клиента - также слишком затратно.

Поэтому тот код который занимается сингналингом и транспортом - живет в одном потоке и обрабатывает множество клиентов через асинхронных не блокирующий ввод-вывод (для пущего удобства можно использовать fiber'ы), а вот математика/енкодеры/декодеры живут в собственных потоках либо потоке. И все это вместе живет в общем процессе.

Но, судя по комментариям, большинству в этой теме многопоточность действительно не нужна

Если учесть тенденцию к применению спец. вычислителей типа GPU... То я таки бы оформлял такую обработку как отдельную службу - и пусть она там, чего хочет, делает - либо многопоточно эти данные перемалывает, либо скидывает на внешние спец. вычислители...

Во-первых GPU далеко не во всех задачах применимы в принципе. А целесообразно применять GPU еще в меньшем классе задач.

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

Никто не запрещает использовать разделяемый двоичный кусок памяти - буферы данных и проч.
Кроме memory-mapping, можно и просто засадить два и более экземпляров Оберон-рантайма в один процесс.
Речь про то, что каждый рантайм - однопоточный и не заморачивается тем, что во время сборки мусора кто-то ещё шарится по объектам языкового уровня ))
И программист не заморачивается тем, что каждый метод может быть вызван конкурентно...
А с разделяемыми двоичными данными никаких проблем.

А теперь представим, что один поток завис при расчёте кадра. В случае вытесняющей многозадачности мы "потеряем" одного клиента, а в случае не вытесняющей - "ляжет" сервер.

Так завис поток? Или кооперативный актор? Выше я же описал конструкцию вполне многопоточную, только каждому потоку - изолированное объектное пространство.

В рамках однопоточной же модели делается отдельный служебный поток, который контролирует лимит времени каждому актору, при перерасходе - делает исключение (в ББ такой поток реагирует на Ctrl-Break, но ничто не мешает его научить другой логике). Watchdog, короче.

Еще раз - передача данных между двумя процессами, даже через shared memmory, работает медленней чем внутри процесса между потоками. Примитивы синхронизации между двумя процессами также сложнее и тормознее чем между двумя потоками в одном процессе.

Я не спорю что для ББ (в том состоянии в котором он сейчас) это решение (в нескольких процессах) было бы наиболее приемлемым (а тормоза из за разных процессов играли бы роль не сильно заметную на фоне общей тормознутости генерируемого компилятором ББ кода), но не нужно доказывать что это решение оптимально для всех других инструментов и ЯП. Это просто не так. Мы пробовали.

А ты вкурил тот вариант, который я тебе выше предложил?
N ядер Оберона в одном процессе ОС. И имей сколько угодно общей памяти, вне-языково-управляемой.

Этот момент я упустил, да. Много рантаймов внутри одного процесса - это, пожалуй, хорошее решение (по крайней мере я не вижу особых проблем там прямо сейчас).

Как предлагаешь между ними передавать жиррные бинари? Также как это делается между легковесными потоками в erlang'e? (то есть вопрос о том, кто владеет данным вот куском памяти и кто ответственнен за его убиение, сборщик мусора тут не слишком годится, зато хорошо подходит счетчик ссылок, именно так в erlang'e и сделано).

Хотя, если у нас это "буфер обмена" между рантаймами на постоянной основе для конкретной задачи, то он может создаваться и убиваться явным образом в момент запуска и останова системы. То есть в этом случае, если не пытаться обобщить задачу, а решать конкретную, то решение будет значительно проще и, видимо, эффективнее.