Pull to refresh
9
0
Кирилл @EvilBlueBeaver

User

Send message

Асинхронный дизель в наличии от тех же авторов, просто в отдельном крейте. Правда там есть пару неприятных особенностей, которые авторы решить не могут, а я у себя чинил костылем.

А причем тут тогда thread-local storage? И как он помогает в достижении thread-safe, что это прям обязательное условие для всех thread-safe языков, как вы писали выше?

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

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

Да и опять же я не уверен, что именно thread local storage там используется, а это не просто схожая по концепциям вещь.

Я слабо себе представляю как работает thread local storage и beam тут ни при чем вообще.

Я пишу на эрланге профессионально уже больше 13 лет мне не надо его рекламировать)

Тот же rustler я использовал (да и на си nifы писал), но у них есть куча ограничений. Они блокирующие и блокируют весь шедулер, поэтому что-то долгое там не сделаешь. В целом-то это можно обойти, конечно, но это надо заморачиваться. Пример того, как в таком случае морочатся, вы можете найти в исходниках jiffy.

Вот вообще нифига не так, я буквально на днях это проверял. То есть делается функция с авейтом внутри и после авейта все делается в другом физическом потоке. Это буквально весь смысл всей этой схемы. Даже в том же расте чтобы что-то запустить в асинхронщине - оно должно быть Send + Sync, чтобы рантайм мог этим жонглировать.
По поводу дорогого удовольствия. Ничто не дается бесплатно. В том же эрланге куча оверхеда и тормозов, но зато меньше вариантов прострелить себе ногу. И тут надо выбирать, что тебе важнее.

Я слабо себе представляю, как оно должно работать в случае всяких thread pool с постоянным переключением green threads между разными физическими потоками. Сам я на практике такое не использовал, но если вы мне объясните, я буду не против.

В общем-то ничего общего нет. И как бы вас thread-local storage вообще никто не заставляет использовать. А тут нет выбора в принципе, у вас буквально процессы изолированные, передавать можно только копированием (с некоторыми исключениями, но это уже не особо важные в контексте этого разговора подробности).

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

Как из моего комментария вообще следует, что я actix использую? к слову, я его не использую.

Спасибо, я в курсе) вы можете выше найти комментарий, где я про их внутреннее устройство немного рассказывал)

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

Тут согласен, в нем очень сложно (хоть и не невозможно) себе прострелить ногу при работе с потоками. Скорее всего просто не скомпилится.

https://github.com/actix/actix

а токио это про асинхронщину, а не про потоки в первую очередь.

Хотя actix сделан поверх токио, но все же это по сути эрланговая модель.

Спасибо за предложение. Я подумаю над этим. Никогда не пробовал)

У меня нет такого количества экспертизы, чтобы прям туториалы для других писать. Я исходники упоминаемые в вышеприведенном комменте только сегодня посмотрел, чтобы убедиться, не ошибаюсь ли я. Было бы неловко, если бы наврал)

А еще если вы посмотрите в исходники токио, то там в одном из вариантов будет структура Semaphore с атомиком внутри. Вас это тоже триггернет и будете говорить, что это настоящий семафор?

И? Вы там видите мьютексы или семафоры?

Предварительное уточнение, я с std::sync давно не работал напрямую и использовал в основном из tokio асинхронные варианты. Относительно недавно в основной раст добавили каналы из crossbeam, которые считались лучшей версией, нежели основные. Старые были без мьютексов, но думаю это не актуально.
https://doc.rust-lang.org/1.66.0/src/std/sync/mpsc/mpsc_queue.rs.html

По поводу того, что вы скинули. я бегло глянул, где оно там используется.
Во первых там есть 2 варианта каналов: bounded и unbounded
В bounded случае канал ограничен размером и используется array::Channel (ну или zero::Channel, если ограничить в ноль размер),
и SyncWaker там используется, чтобы разбудить тех отправителей, которые были добавлены в очередь, когда канал был забит.
В обоих случаях SyncWaker используется, чтобы разбудить получателей, если канал был пустым и кто-то туда что-то прислал.
То есть это некая оптимизация для пустых (или полных в bounded случае) каналов.

Сама отсылка в очередь (и забор из нее) делается через cas, спинлок и вот это вот все.
это вы можете посмотреть в start_send(start_recv) методах соответствующих Channel (array, list и zero).

Заодно глянул как оно там в tokio. Eсли в std(после мерджа crossbeam) все сделано на основе mpmс, просто при создании создается всего один получатель и mpmc превращается в mpsc, то в токио оно сразу идет как mpsc. Поэтому там нет таких же Waker для получателей, там идет один AtomicWaker и он без мьютексов, а на атомиках (как можно понять по названию). А для отправителей, да, идет семафор, но исключительно для задач ограничения размера канала. Сама же отправка точно так же идет через cas.

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

Спасибо за то, что указали на это и дали повод чуть подробнее изучить.

Information

Rating
5,072-nd
Location
Волгоград, Волгоградская обл., Россия
Date of birth
Registered
Activity