AI
Ребят, я не понимаю, при чем тут ОС? Стандартный RwLock обязан заблокировать тред, если RwLock начинают читать, когда в него кто-то пишет
У тебя там starving может случиться
Size: a a a
2020 July 12
AI
Зависит например от системного шедулера процессов
AI
https://www.reddit.com/r/rust/comments/f4zldz/i_audited_3_different_implementation_of_async/
Windows: Readers and writers are fairly queued
Linux: Readers will starve the writers
macOS: Readers and writers are fairly queued
Windows: Readers and writers are fairly queued
Linux: Readers will starve the writers
macOS: Readers and writers are fairly queued
KR
То есть, если я захвачу Mutable на запись, начну что-то делать 5 минут, и потом отпущу Mutable, то связанные с его сигналом таски не заблокируются? Заблокируются конечно. Токио попробует пополить где-нибудь фьючер, связанные с сигналом, и будет ждать все 5 минут вместе с тредом, в котором таска сидит
Аааа... там .lock_mut() в АПИ торчит, ты про это. Ну не юзай его и всё. Юзай просто .set() и у тебя не будет подобных ситуаций.
KR
Зависит от ОС не?
Ну... "ебанет? не должно..."(с)
AI
Ну... "ебанет? не должно..."(с)
Ты на чем рвлок тестил?
AI
На какой ос?
KR
На линуксе на старвинг не налетали. Возможно нагрузки не те. Но я сомневаюсь, что в пользовательском UI могут быть такие нагрузки.
KR
Тем более что асинхронный rwlock будет страдать тем же
KR
Это ведь обычный RwLock обёрнутый в футуру со свистоперделками.
AI
Тем более что асинхронный rwlock будет страдать тем же
Finally, tokio::sync::RwLock uses a waiter queue where readers acquire 1 permit from a semaphore, and writers acquire all permits. The waiter queue interleaves read and write lock acquisitions in FIFO order, so it does provide a task-fair locking policy! Hooray!
AI
Давай не будем гадать
IL
Аааа... там .lock_mut() в АПИ торчит, ты про это. Ну не юзай его и всё. Юзай просто .set() и у тебя не будет подобных ситуаций.
Если я просто .set юзать буду, то потеряется смысл в контейнере. Здесь прочитал данные, потом что-то с ними сделал, потом записал, а прочитанные данные уже потеряли актуальность.
AI
Это ведь обычный RwLock обёрнутый в футуру со свистоперделками.
Ты проверял? Ну хоть мою ссылку глянь
AI
Там много инфы
AI
Проше не юзать блокирующие примитивы синхронизации в асинке
AI
Раз есть асинхронные
IL
@tyranron То есть, чтобы обойти проблему синхронной блокировки на RwLock в асинхронном коде вы фактически предлагаете его не юзать, как RwLock, а использовать как такой Atomic. Но тогда зачем автор вообще вводил RwLock? Можно было каналом передавать последнее значение, и всё
KR
@tyranron То есть, чтобы обойти проблему синхронной блокировки на RwLock в асинхронном коде вы фактически предлагаете его не юзать, как RwLock, а использовать как такой Atomic. Но тогда зачем автор вообще вводил RwLock? Можно было каналом передавать последнее значение, и всё
Каналы не дают interior mutability.
И нет, я говорю лишь о том, что если Вы боитесь заблокировать тяжелой блокироющей операцией Mutable, то не держите .lock_mut() пока её выполняете. Наиболее простой способ не отстрелить себе ногу - просто юзать .set().
Если же Вам надо atomic check-before-write, то да, юзайте .lock_mut(), но с умом.
И нет, я говорю лишь о том, что если Вы боитесь заблокировать тяжелой блокироющей операцией Mutable, то не держите .lock_mut() пока её выполняете. Наиболее простой способ не отстрелить себе ногу - просто юзать .set().
Если же Вам надо atomic check-before-write, то да, юзайте .lock_mut(), но с умом.
d
@diaevd Нормально ли, что в функции поллинга фьючеров сигналов futures-signals каждый раз делают read-lock блокирующего RwLock?
да — это норм
но я уже говорил, лучше сделать форк и использовать RwLock их токио, как допилят в futures можно будет слезть со своего форкать, если он уже не превратится в самостоятельный проект)
но я уже говорил, лучше сделать форк и использовать RwLock их токио, как допилят в futures можно будет слезть со своего форкать, если он уже не превратится в самостоятельный проект)