Ребят, вам бы хватило возможности шарить память между 127 потоками?

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

Не понял какая связь между вопросом и вторым предложением, а так же откуда ограничение в 127 Если что, возможности шарить память мне бы не хватило, ещё нужны семафоры и/или мьютексы

Да, ограничение вокруг мьютекса и крутится. Т.е. максимальное количество обращений из разных потоков будет числом, которое помещается в без знаковое 8-битное число, т.е. 127, где 0 — лок потока.

А почему 8-ми битное?

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

Ты же понимаешь что на уровне процессора всё равно идёт манипуляция числом в 64 разряда (ну или какая у тебя там архитектура, вряд ли условный z80)?

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

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

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

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

Надеюсь до вечера альфа-версию своей либы смогу в чат закинуть. Я вчера рассказывал как она работает, по сути просто обертка, которая позволяет чуть удобнее работать с потоками и шарить данные. (Это нужно для двух целей — совместное использование между потоками и передача результата без издержек на копирование.) Сейчас прикручиваю атомики и мьютекс и начну функционал допиливать, а то пока маловато возможностей. (Работать уже можно, но хотелось бы дать больше контроля)

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

Что-то типа такого делаешь? https://github.com/metarhia/noroutine

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

В общем накидал вроде, голова уже не варит, на доку не хватило сил, нужно убегать по делам. https://github.com/LimitR/ad-worker Можно протестить и всю критику пулреквестами отправлять)) Ребят, пожалуйста, не цепляйтесь к ошибкам в названиях, или комментариях, это всё мелочи и исправлю. Мне главное понять, чего не хватает по функционалу, чтоб прикрутить. Сегодня вряд ли своей головой допру. (Скорее всего есть проблемы атомиками, проверьте)

Он усложняет код и отладку в разы: лолк/анлок/синхронизация/рейскондишены и тд

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

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