LINUX.ORG.RU

Какие накладные расходы для ОС несут блокированные потоки?

 ,


1

4

Ввиду отсутствия нормального акторного фреймворка под Rust, возникла крайне неодназначная по началу идея, которая со временем стала мне казаться довольно любопытной. std::thread + std::sync::mpsc = актор на выделенном потоке. В терминологии akka это актор на пиннед диспетчере. И собственно а почему бы и нет? По каналам сообщения идут в строгом порядке один за одним, поток обладает собственным состоянием, которое не может быть изменено вне хендлера сообщений. Он может реализовывать различные варианты поведения, заменяя их по факту приема сообщений.

Проблема возникает в следующем - акторов может быть очень много, потенциально тысячи. Очевидно что все их потоки будет 99% времени находится в состоянии ожидания и будут игнорироваться планировщиком. Но все же хочется понять, какие могут быть минусы у такого решения по части накладных расходов за огромное количество потоков?

Ответ на: комментарий от tailgunner

Сходи по ссылкам

Чтиво интересное, конечно. Но было бы проще, если бы ты просто дал определение зелёным нитям, из которого ты исходишь. Иначе мы скатываемся в бесконечное: «автор хотел сказать, что…»

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Но было бы проще, если бы ты просто дал определение зелёным нитям, из которого ты исходишь.

Мое личное? «Нить без стека ядра». Т.е. юзерспейсный стек есть, ядерного - нет. Наверное, можно сказать «нить, состояние которой не отслеживается ядром».

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Вот. Хорошо, что спросил явно.

Из текстов я понял, что green threading это неявное и всеобъемлющее использование переключения задач в юзерспейсе, а async/await — явное указание, по выбору программиста.

Я пока не могу сообразить, можно ли async/await сделать без переключения стеков. Если можно, то все мои вопросы отпадают.

i-rinat ★★★★★ ()
Ответ на: комментарий от tailgunner

Ну вроде как select как раз из-за этого хуже poll.

Мои кривые руки получили примерно такую разницу на коде с узким местом в чтении записи памяти:

-------------------------------------------------------------                                                   
Benchmark                      Time           CPU Iterations                                                    
-------------------------------------------------------------                                                   
BM_stamp                     113 ns        113 ns    6158833                                                    
BM_stamp_with_threads        142 ns        142 ns    4906079
pon4ik ★★★★★ ()
Ответ на: комментарий от i-rinat

а async/await — явное указание, по выбору программиста.

Я называю `async`/`await`-ом всю работу по добавлению асинхронности в Rust - и языковые конструкции, и то, во что они рассахариваются, и даже runtime-поддержку.

Я пока не могу сообразить, можно ли async/await сделать без переключения стеков.

Сейчас не могу найти ссылку, но я видел вариант рассахаривания `async fn`, в котором всё состояние функции хранилось в (автоматически создаваемом компилятором) объекте, так что одна нить ОС могла исполнять любое количество `async fn`.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от pon4ik

Ну вроде как select как раз из-за этого хуже poll.

Из-за чего «этого» - прохода по неактивным объектам? Мне кажется, это было из-за совершенно идиотских параметров select (битовые карты, епт). В любом случае, я уверен, что планировщик Linux не ходит по спискам неготовых нитей.

tailgunner ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

То есть в расте не нужна говно-библиотека (как в питоне) на которую всё завязано и без которой магия не работает?

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

как и везде

В джаваскрипте не нужна.

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

WitcherGeralt ★★ ()
Ответ на: комментарий от tailgunner

вариант рассахаривания `async fn`, в котором всё состояние функции хранилось в (автоматически создаваемом компилятором) объекте

В текстах по ссылкам как раз об этом и написано, да. Без конкретных реализаций, просто как один вариант направления развития.

i-rinat ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Наркомания же какая-то

И не говори. Создатели явно были под LSD. Райан отказывается делать пакетный менеджер. Говорит, что это у него аки браузер. Пишешь deno.exe https://my-site/app/index.ts — оно загружается со всеми зависимостями, компилится и запускается

spoonbob ()
Ответ на: комментарий от i-rinat

Я пока не могу сообразить, можно ли async/await сделать без переключения стеков. Если можно, то все мои вопросы отпадают.

AFAIK именно это и подразумевалось под аналогичной фичей, которую всё хотели в C++ принять. Думаю Rust по этому же пути пошёл. Смысл в том, что компилятор сам разрезает функцию на коллбеки, и вместо стека целиком (как в файберах) генерирует объект-контекст только с нужными «локальными» переменными (как в лямбдах).

snizovtsev ★★★ ()
Ответ на: комментарий от aiive

1. потоки thread (истинная многопоточность) - механизмом ос 2. асинхронный / ввод вывод async/await - механизм ос 3. легковесные потоки green thread - механизм рантайма языка, которые инкапсулируют в себя (являются фасадом): п.1 истинную многопоточность + п.2 асинхронный / ввод вывод async/await + п.3 псевдо многопоточность (канкаренси) когда несколько гринтредов конкурируют за один поток ос.

Cergoo ()
Ответ на: комментарий от Cergoo

2. асинхронный / ввод вывод async/await - механизм ос

нет, механизм ос это неблокирующий операции

асинхронный ввод/вывод и async/await реализованы либо в языке, либо в виде либ к языку

aiive ()
Ответ на: комментарий от Serbis

developing under strongly impact from

Я бы всё же написал «developed with strong influence from».

This runtime is realize

This runtime implements.

this module is heavily relies

is лишнее.

Короче, над языком документации надо поработать.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

Serbis ()