Я слабо себе представляю, как оно должно работать в случае всяких thread pool с постоянным переключением green threads между разными физическими потоками. Сам я на практике такое не использовал, но если вы мне объясните, я буду не против.
В общем-то ничего общего нет. И как бы вас thread-local storage вообще никто не заставляет использовать. А тут нет выбора в принципе, у вас буквально процессы изолированные, передавать можно только копированием (с некоторыми исключениями, но это уже не особо важные в контексте этого разговора подробности).
По сути это «ос внутри процесса». Там создаются внутренние виртуальные полностью изолированные друг от друга процессы, которые общаются друг с другом только посредством передачи сообщений. У вас физически нет разделяемой памяти и не нужно ничего синхронизировать. Это дает определенные преимущества в определенных программах, но это явно не применимо для всех возможных задач.
Тогда можно в целом считать, что в эрланге-то по сути тоже зеленые потоки, а не настоящие и исходный комментарий был неверный. Но мне кажется он был немного про другое, про то что в подобных моделях пусть даже и в зеленых потоках, но создан такой подход, что примитивы синхронизации не требуются как таковые. Потоки максимально изолированы и все межпоточное взаимодействие осуществляется через контролируемые очереди(каналы, мейлбоксы и так далее). Благодаря чему целый класс проблем просто исключается из повестки.
У меня нет такого количества экспертизы, чтобы прям туториалы для других писать. Я исходники упоминаемые в вышеприведенном комменте только сегодня посмотрел, чтобы убедиться, не ошибаюсь ли я. Было бы неловко, если бы наврал)
А еще если вы посмотрите в исходники токио, то там в одном из вариантов будет структура 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.
Итоги: мьютексы (и семафоры) используются, тут вы правы. Используются ли они для реализации самой очереди и разрешения конфликтов в ней при вставке или заборе очередного сообщения? Нет, не используются. Для чего они используются? Для оптимизации случаев пустых или переполненных каналов. Можно ли без них? Я не знаю.
Спасибо за то, что указали на это и дали повод чуть подробнее изучить.
Так я нигде и не утверждал, что они быстрее мьютексов. Более того я прекрасно понимаю, что оно в негативном сценарии в отличие от мьютекса еще и проц будет жрать как не в себя. Разница только в том, что в одном случае все будет намертво висеть, если ресурс занят, а в другом случае возможны варианты. Реальный сценарий реальному сценарию рознь. Если втупую взять какую-то общую структуру, которая шарится на много потоков и поменять мьютексы на lock-free, то почти наверняка оно хуже и будет. Все системы с обменом сообщениями, с которыми я работал и работаю подразумевают, что таких глобальных данных под мьютексом, в которые ломятся все кому не лень, нужно избегать и заменять на отдельные сообщения между отдельными потоками. В некоторых случаях у вас даже возможности такой не будет пошарить данные, например в эрланге(ну формально, конечно, можно и там извратиться, но это надо прям очень сильно захотеть). Но благодаря этому многопоточная разработка становится в разы проще и понятнее и помогает избежать кучи проблем. Об этом (как мне показалось) и было оригинальное сообщение в треде. Ну и да, даже очереди с мьютексами (а то и вообще с RWLock) под капотом с точки зрения отсутствия возможности отстрелить себе ногу в разы лучше, чем голые мьютексы. Да, оно будет очевидно медленнее, но избавит от кучи головной боли, о которой в частности и написана статья.
По поводу видео, его я посмотреть не успел, но заголовок говорит о том, что там описывается mpmc, мои примеры выше работают либо в варианте mpsc, либо в варианте spsc вообще.
Дождаться-то как раз и несложно. Если у вас такой огромный поток сообщений, то конкуренция будет на вставку, а консьюмер в спинлок попадать не будет. Ну разве что консьюмер выгребает сообщения настолько быстро, что длина очереди в среднем нулю равна.
Все эти очереди потокобезопасны и грин треды тут вообще ни при чем. Тем более что зачастую грин треды вполне себе на обычных потоках делаются (шедулеры в эрланге или какой нибудь тредпул в токио в расте).
Ну и там нет примитива исключительного доступа как правило, в этом и смысл lock-free. Ну то есть нет такого, чтобы какой-то поток залочил себе запись, а все остальные ждут, когда он закончит.
Атомики и мьютексы вообще несравнимые вещи и то как они реализованы очень сильное значение имеет.
Я не знаю, что вы подразумеваете под очередями сообщений, но все известные мне и широко используемые очереди сообщений, которые используются для общения именно между «тредаии», мьютексов не используют, насколько я знаю. Я про эрланговые мейлбоксы, растовые mpsc и гошные каналы. Ну и «самопальные» очереди в тех случаях, где оно не встроено, тоже пилят на всяких атомиках и прочем обычно.
И в Google Play и в AppStore прекрасно работают схемы с подписями чеков приватным ключом стора и проверкой их без непосредственного обращения к самому стору со стороны бэкенда. Это в некоторых случаях, правда, добавляет других проблем.
Я слабо себе представляю, как оно должно работать в случае всяких 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.
Итоги: мьютексы (и семафоры) используются, тут вы правы. Используются ли они для реализации самой очереди и разрешения конфликтов в ней при вставке или заборе очередного сообщения? Нет, не используются. Для чего они используются? Для оптимизации случаев пустых или переполненных каналов. Можно ли без них? Я не знаю.
Спасибо за то, что указали на это и дали повод чуть подробнее изучить.
Так я нигде и не утверждал, что они быстрее мьютексов. Более того я прекрасно понимаю, что оно в негативном сценарии в отличие от мьютекса еще и проц будет жрать как не в себя. Разница только в том, что в одном случае все будет намертво висеть, если ресурс занят, а в другом случае возможны варианты.
Реальный сценарий реальному сценарию рознь. Если втупую взять какую-то общую структуру, которая шарится на много потоков и поменять мьютексы на lock-free, то почти наверняка оно хуже и будет. Все системы с обменом сообщениями, с которыми я работал и работаю подразумевают, что таких глобальных данных под мьютексом, в которые ломятся все кому не лень, нужно избегать и заменять на отдельные сообщения между отдельными потоками. В некоторых случаях у вас даже возможности такой не будет пошарить данные, например в эрланге(ну формально, конечно, можно и там извратиться, но это надо прям очень сильно захотеть). Но благодаря этому многопоточная разработка становится в разы проще и понятнее и помогает избежать кучи проблем.
Об этом (как мне показалось) и было оригинальное сообщение в треде. Ну и да, даже очереди с мьютексами (а то и вообще с RWLock) под капотом с точки зрения отсутствия возможности отстрелить себе ногу в разы лучше, чем голые мьютексы. Да, оно будет очевидно медленнее, но избавит от кучи головной боли, о которой в частности и написана статья.
По поводу видео, его я посмотреть не успел, но заголовок говорит о том, что там описывается mpmc, мои примеры выше работают либо в варианте mpsc, либо в варианте spsc вообще.
Дождаться-то как раз и несложно. Если у вас такой огромный поток сообщений, то конкуренция будет на вставку, а консьюмер в спинлок попадать не будет. Ну разве что консьюмер выгребает сообщения настолько быстро, что длина очереди в среднем нулю равна.
Разговор начался с того, что было указано, что без мьютексов это невозможно. Это возможно. Плюсы и минусы этих механизмов - это уже отдельный вопрос.
Все эти очереди потокобезопасны и грин треды тут вообще ни при чем. Тем более что зачастую грин треды вполне себе на обычных потоках делаются (шедулеры в эрланге или какой нибудь тредпул в токио в расте).
Ну и там нет примитива исключительного доступа как правило, в этом и смысл lock-free. Ну то есть нет такого, чтобы какой-то поток залочил себе запись, а все остальные ждут, когда он закончит.
Атомики и мьютексы вообще несравнимые вещи и то как они реализованы очень сильное значение имеет.
Я не знаю, что вы подразумеваете под очередями сообщений, но все известные мне и широко используемые очереди сообщений, которые используются для общения именно между «тредаии», мьютексов не используют, насколько я знаю. Я про эрланговые мейлбоксы, растовые mpsc и гошные каналы. Ну и «самопальные» очереди в тех случаях, где оно не встроено, тоже пилят на всяких атомиках и прочем обычно.
Lock-free queue
И в Google Play и в AppStore прекрасно работают схемы с подписями чеков приватным ключом стора и проверкой их без непосредственного обращения к самому стору со стороны бэкенда. Это в некоторых случаях, правда, добавляет других проблем.