я говорю про синхронный не-блокирующий код в стиле Gо, а не про синхронный в стиле C/C++, это, товарищ, вещи абсолютно разные

Вот да. Любое взаимодействие убивает производительность

VSC

Там плагин нужен какой-то?

https://code.visualstudio.com/docs/languages/go

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

shared mutable state без мьютексов говорите? что-то я вам не верю, коллега

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

что?!))) обычный многопоток на C++/Rust/Java может быть гораздо эффективнее Goroutine. Но писать его будет гораздо сложнее)) вы думаете green thread'ы зря чтоль придумали, если на простых потоках и без того легко писать?)))

что?!))) обычный многопоток на C++/Rust/Java может быть гораздо эффективнее Goroutine. Но писать его будет гораздо сложнее)) вы думаете green thread'ы зря чтоль придумали, если на простых потоках и без того легко писать?)))

Ещё раз напоминаю про libdill

shared mutable state без мьютексов говорите? что-то я вам не верю, коллега

Я ещё раз повторяю. Можно спокойно написать многопоточный код, который будет практически совпадать с кодом на Го, просто он будет куда менее эффективным, потому что вместо горутин там будут обычные потоки.

green thread'ы в C, это таки не green thread'ы в констексте runtime'а языка

С разморозкой https://ru.m.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C

обычные потоки менее эффективны горутин? с чего такое мнение?

обычные потоки менее эффективны горутин? с чего такое мнение?

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

транзакции это банальный mutex под капотом, али нет?

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

А это уже детали реализации

проблема в том что так или иначе mutable shared state требует синхронизации. Самая низкоуровневая примитива синхронизации это mutex, он в основе всех механизмов синхронизации. lock-free алгоритмы и структуры существуют, но не все проблемы решают, зависит от задачи. Порой mutex просто неизбежим

ну при большом количестве явно эффективнее и производительней (иначе просто вместо них потоки бы юзали и не парились)

мьютекс - не самый низкоуровневый

а что тогда?

а чем горутина так принципиально отличается от потока?

атомарные операции

тем что она не поток а лишь абстракция над ним которая обходится тебе ценой user-space runtime scheduler'а и 4кб памяти?

именно это я и пытаюсь сказать, что работа с горутинами в принципе мало отличается от работы с потоками, потому что в принципе это почти одно и то же, за исключением производительности

мне почему то кажется, что можно изхитриться и сделать приоритеты для горутин

нет, никак, вообще никак, потому-что goroutine scheduler понятия не имеет какая из горутин важнее, ему плевать

но гипотетически можно влезть в код шедулера и сделать ему приоритеты

Гипотетически - да, практически - нет. У гугла нет планов встраивать приоритеты в Go scheduler ибо для таких вещей как коллективная обработка запросов API - она не нужна, а 3D движок на Go никто писать не будет. Однако я считаю можно бы конечно было и добавить, чтоб некоторые горутины намеренно планировались на приоризированных системных потоках или вообще запускались в своих отдельных.. было бы круто, но я не знаю какие этому могут быть последствия

потоки на которых запускаются горутины - не исключение

нет, IPC это вам не shared memory, он дорого обойдётся как в плане написания кода так и в плане производительности

Вообще-то нет. Те же двери на солярке дешевые

что значит помехи?

IPC всегда дороже и сложнее shared process memory

Правильно сделанный ipc - нет. См solaris doors

Правильно сделанный ipc - нет. См solaris doors

Гипотетически - да, практически - нет. У гугла нет планов встраивать приоритеты в Go scheduler ибо для таких вещей как коллективная обработка запросов API - она не нужна, а 3D движок на Go никто писать не будет. Однако я считаю можно бы конечно было и добавить, чтоб некоторые горутины намеренно планировались на приоризированных системных потоках или вообще запускались в своих отдельных.. было бы круто, но я не знаю какие этому могут быть последствия

Ты можешь запустить в отдельном.

однако наивно предположу что под словами "правильно сделанный" уже кроется сложность

процессе?) удачи в IPC)

Там просто и изящно: процесс экспортирует набор своих функций. Вызывающий код оказывается в контексте вызываемого процесса

Да в чем проблема с ipc? Что ж вы так его демонизируете?

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

Кольцо в shm

shared memory это весчь прикольная, но не кросс-платформенная

А где ее нет?

насколько мне известно на мобилках её нет совсем. А так она ещё и реализуется на разных системах совершенно по разному, там есть свои нюансы. Как-то очень давно занимался этой тематикой но уже забыл большинство деталей

И оно становится заметным только на больших объемах