Что приводит к созданию 2х мьютеусов

Зачем?

Я выше уже объяснил зачем

Чтобы быстрые файберы не блокировались и отрабатывали быстрее

Если уж и убирать - так наоборот внутренний synchronized мьютекс

https://run.dlang.io/is/okfCP8

ето б в статью оформить))

Если уж и убирать - так наоборот внутренний synchronized мьютекс

Вот верно

А не то, как ты это сделал

Лол наконец то ты признал то что я тебе 2 дня пытаюсь донести :)

Что?

Для файбера мютекс не нужен

Я тебе написал как нужно делать ещё черт знает когда

Ты читать умеешь?

Для файбера мютекс не нужен

Ты писал что он не нужен :)

Не нужен

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

Но не файберу

Он нужен для того чтобы другие файберы пропустить вперед себя и не блокировать

Вот с такой формулировкой я соглашусь

Но именно это я бы реализовал по другому

Что-то типа того

https://run.dlang.io/is/6B5Fkx

Хотя лучше сделать стратегию.

Будет красивей

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

но бесконечный цикл в котором проверяются данные сокета грузит ядро на 100% или надо sleep ставить?

через socketset надо проверять изменения в сокетах

все ок будет

проверка состояния сокетов либо блокируется, пока нет активностей, либо таймаут можно ставить, либо в неблокирующем режиме проверить и дальше делать что то

Сокеты делаются не блокирующими и проверяется через select

Внутри цикла делается маленький слип

Или юзается какой-то event loop

В нем это с коробки

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

Передача данных между ними - отдельный разговор

Можно сделать общую память и писать в нее

Или все данные тоже передавать через эти сокеты

Так можно уйти от блокировок

НО, тут вопрос, будет ли это быстрее обычного мьютекса

НО, тут вопрос, будет ли это быстрее обычного мьютекса

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

Конечно

Но это на низком уровне

Ниже некуда

Там оно атамарно происходит

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

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

If the result of the operation indicates that there was no contention on the lock, the call to pthread_mutex_lock returns without ever context switching into the kernel, so the operation of taking a mutex can be very fast. Only if contention was detected does a system call (called futex) and context switch into the kernel occurs that puts the calling process to sleep until the mutex is released.

http://opensourceforu.com/2013/12/things-know-futexes/ вот тут больше мяса, реализация для linux

A hash table maps the futex ID (uaddr param, above) to per-thread/per-process futex_q structs. When futex_wait() is called by a thread, a new futex_q object is created for it and added to the appropriate hash table entry. When futex_wake() is called, the same is used to wake up the sleeping process.

Когда кто-то отпустил мьютекс, то ядро идет в хеш таблицу и смотрит кто там еще ждет, будит ожидающий тред и передает исполнение ему. Никаких циклов :)

Хм...

Круто

Считал, что оно работает по другому

Когда кто-то отпустил мьютекс, то ядро идет в хеш таблицу и смотрит кто там еще ждет, будит ожидающий тред и передает исполнение ему. Никаких циклов :)

и правда круто, спасибо

Мьютексы не такие уж и медленные, как их многие считают

Но лучше писать код без их использования

а почему они вообще должны быть медленными?

а почему они вообще должны быть медленными?

Переключение в режим ядра?

Переключение в режим ядра?

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

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

а если есть один общий shared объект, то что бы не использовать мьютекси для роботы с ним, можно использовать message passing, pairSockets, но по сути все равно нужно будет выстраивать очередь желающих с ним поработать и вызывать их. т.е. будет то же блокирование, но по другому сделаное. т.е. не всегда же есть решение лучшее, чем мьютекс?

самое главное что бы потоки не простаивали

я сейчас о крайнем случае - есть N потоков и каждый из них только и работает с общим объектом (случай бессмысленный, конечно). так вот можно ли лучше, чем мьютексы, тут что-то использовать?

я бы вынес работу с объектом в один поток, и туда отсылал бы команды (я так с БД у себя работаю).

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

ну а смысл тогда N потоков использовать? Тогда должны быть распаралеливаемые вычисления

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

ERROR: S client not available

А вот работа с сокетами она разве не через ядро идёт?

Кто нибудь юзал Registered Input/Output (RIO) в винде?

select и epoll это ведь тоже системные вызовы

select и epoll это ведь тоже системные вызовы

Да

я сейчас о крайнем случае - есть N потоков и каждый из них только и работает с общим объектом (случай бессмысленный, конечно). так вот можно ли лучше, чем мьютексы, тут что-то использовать?

Ну смотри. Быстрее чем мьютекс вряд-ли выйдет сделать

Ну смотри. Быстрее чем мьютекс вряд-ли выйдет сделать

Cas?

Если делать какое-то IPC, то ты попадаешь на сериализацию данных

https://ru.m.wikipedia.org/wiki/Сравнение_с_обменом

Сложная техника программирования многопоточного

Но самая скоростная

Ну тут есть другие проблемы:

Если нужно работать не с одним полем, а несколькими

Скажем 3 поля инта

То тут будет жопа

Одно значение изменит один поток, а второе значение другой

Самое верное - это блокировка

В идеале нужно уходить от таких подходов

Если же не уйти от такого

То лично я бы юзал мьютексы

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

Но это будет дольше, чем мьютекс

Хотя, возможно, и правильней. Если в будущем планируется не только несколько потоков, но и несколько серверов.

https://ru.m.wikipedia.org/wiki/Сравнение_с_обменом

интересная штука и примеры хорошие, в Ди видимо такое можно делать используя https://dlang.org/phobos/core_atomic.html

Поставил я себе tilix, довольно крутая штука

Только при запуске почему то ругается на невозможность прочитать какие-то конфиги.

+1. ругается. но я не стал разбираться ибо awesomewm может также

Только при запуске почему то ругается на невозможность прочитать какие-то конфиги.

У меня ок всё

Может вы на ubuntu, а разработчик инженер redhat?))

И для rpm-based всё конфиги в нужных местах?

А что это?

Tilix

у меня ругался на ArchLinux