типа while(mutex.isLocked) { yield; }?

Ну да

Для них получается нужен специальный файберный мьютекс?

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

Файберы - это простые "функции", которые выполняются по очереди в одном потоке

Они последовательны

Я про случай когда у нас во многих тредах крутятся event loop

Вот как vibe core и делает по сути

И libasync так делает, в теории

Им блокировки не нужны, т.к. паралельного доступа нет

Да

И что?

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

Файбер 11 из треда 1 и файбер 21 из треда 2 могут конкурировать за доступ к расшаренному ресурсу

Тут не важно из чего осуществляется длступ

Он из разных потоков - это ключевой фактор

А файбер тут не при чем

вообще да ты прав можно походу просто synchronized секцию использовать и она автоматом подойдет для фиберов

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

@chebotarevp fiber работает только с io параллельно. Все остальное последовательно. То есть 2 fibers не будут одновременно работать с памятью через какой-то объект

следовательно гонки данных нет

Ты говоришь про один тред

аа

А если они в разных то есть

а ты имеешь ввиду несколько threads и там несколько fibers

я понял

да, в этом случае надо. Но fibers тут не при чем

Например у тебя vibe.d работает в 8 тредах, в каждом треде по 200 фиберов

я понял идею

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

Ну это будет не на долго

Он блокируется только на момент записи

Расчет осуществляется до блокировки мьютекса

А блокируется он только на момент присвоение, а это очень быстрая операция.

Ну если у тебя там не пипец какая логика

Но тут других вариантов нет

Либо какое-то IPC с передачей данных по каналу связи, или мьютексы... Выбирай.

Ну или писать без мьютексов и ждать ошибки памяти

Он блокируется только на момент записи

Разве? Он блокируется на все время пока кто-то другой находится в критической секции

И если там мьютекс захватили 7 файберов то 8й будет стоять в очереди и ждать

t.h=7; t.h=8;

Приведет к 2м блокировкам

И если там мьютекс захватили 7 файберов то 8й будет стоять в очереди и ждать

О.о

Захватить может только 1 поток

ну да

Что значит 7 файберов захватило???

Не захватить, а встать в очередь я имел в виду

Ievgenii Kyrychenko: t.h=7; t.h=8;

Тут будет 2 блокировки

И только на момент записи

что за t?

Ну какой-то синхронизирующийся объект

t.h=test();

По логике сперва будет расчет test(), а после блокировка мьютекса

И присвоение

Чтобы минимизировать время блокировки

так это присвоение. Но ведь бывают длинные критические секции

Такие как метод pop из очереди например

Ievgenii Kyrychenko: Ну если у тебя там не пипец какая логика

Вот на поп он и будет блокироваться

Это быстро

Ну тривиальные случаи не интересно рассматривать

Приведи тогда пример

Чтобы я тебя правильно понял

Это надо собирать компилирующийся пример с vibe core

Так напиши

Хоть примерно, чтобы я понимал, что ты имеешь ввиду

Щас запостю, почти доделал пример )

5 мин..

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

ERROR: S client not available

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

В данной конфигурации без мьютекса видно что быстрые файберы отрабатывают уже где-то в самом конце после того как все написали в базу.

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

То есть если делать по обычной через synchronized секции и без оптимизационного файберного мьютекса, то первый же файбер который входит в критическую долгую секцию заторомозит ВСЕ файберы во ВСЕХ тредах, в которых хотя бы 1 файбер также ждет входа в эту секцию.

Довольно популярный кейс - например у тебя vibe.d работает, много файберов раздают статические файлы (картинки и js скрипты) и несколько файберов разбросаны по тредам и пишут что-то в базу/память в эксклюзивном режиме. Тогда в моменты записи в базу у тебя будет останавливаться отдача статики, тогда вообще смысла в асинхронности нет.

Что за глупасть?

Зачем тебе и синхронизация и мютекс?

Так конечно!

Ты же явно блокируешь мютекс, а потом ещё раз блокируешь мютекс в синхронизационном объекте

Конечно так будет все заблокированно

Ну вот то есть yield с мьютексом для файберов полюбому нужен.

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

Нет

> Ты должен рассчитать данные, Ну вот тело метода write() это и есть рассчет данных.

Там могут бысть разные алгоритмы, невозможно все свести только к одной операции записи.

Расчет не должен быть в мьютексе

Он должен быть до его захвата

А где? Если он должен быть атомарным?

Расчет?

Да

Зачем?

Ну задача такая

Что за вопросы? =)

Вычитка данных для его расчетов может быть атомарной, а вот расчет не должен быть таковым

есть что-то типа mingw для D? чтобы собирать программы для винды на линуксе

есть что-то типа mingw для D? чтобы собирать программы для винды на линуксе

Не знаю

есть что-то типа mingw для D? чтобы собирать программы для винды на линуксе

Можно под wine dmd запускать для простых случаев

знаю, и dub можно для более сложных, просто понадеялся, что есть нативное решение

знаю, и dub можно для более сложных, просто понадеялся, что есть нативное решение

Ну я имел ввиду dub

Сложные случаи это когда надо 64 бита и либы

Например gtkd

Это не сложные