A
Ну это надо тестить, а сама идея хорошая
Size: a a a
2020 July 29
D
Ну это надо тестить, а сама идея хорошая
A
типа вечные локи из-за непрекращающегося потока читателей
Гипотетически на чтение лока быть не должно, или он менее приоритетный чем на запись
D
Гипотетически на чтение лока быть не должно, или он менее приоритетный чем на запись
ну как это не должно, а как писатель поймёт, что писать нельзя?
D
вот с приоритетом да — это уже интересней
A
ну как это не должно, а как писатель поймёт, что писать нельзя?
С одной стороны ты прав, с другой зависит от объектов, можно реализовать транзакционник)
D
так, например, сделано в parking_lot:
This lock uses a task-fair locking policy which avoids both reader and writer starvation. This means that readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock. Because of this, attempts to recursively acquire a read lock within a single thread may result in a deadlock.
https://docs.rs/parking_lot/0.11.0/parking_lot/type.RwLock.html
This lock uses a task-fair locking policy which avoids both reader and writer starvation. This means that readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock. Because of this, attempts to recursively acquire a read lock within a single thread may result in a deadlock.
https://docs.rs/parking_lot/0.11.0/parking_lot/type.RwLock.html
D
С одной стороны ты прав, с другой зависит от объектов, можно реализовать транзакционник)
ну вот да, начинаются сложности) в мутексом всё сильно проще =)
A
ну вот да, начинаются сложности) в мутексом всё сильно проще =)
Универсальней)
D
да
A
так, например, сделано в parking_lot:
This lock uses a task-fair locking policy which avoids both reader and writer starvation. This means that readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock. Because of this, attempts to recursively acquire a read lock within a single thread may result in a deadlock.
https://docs.rs/parking_lot/0.11.0/parking_lot/type.RwLock.html
This lock uses a task-fair locking policy which avoids both reader and writer starvation. This means that readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock. Because of this, attempts to recursively acquire a read lock within a single thread may result in a deadlock.
https://docs.rs/parking_lot/0.11.0/parking_lot/type.RwLock.html
Видел, но юзал токийский, возможно там реэкспорт
D
Видел, но юзал токийский, возможно там реэкспорт
ненене, в токио свои примитивы, но там тоже какой-то fair rwlock
D
Fairness is ensured using a first-in, first-out queue for the tasks awaiting the lock; if a task that wishes to acquire the write lock is at the head of the queue, read locks will not be given out until the write lock has been released
https://docs.rs/tokio/0.2.22/tokio/sync/struct.RwLock.html
https://docs.rs/tokio/0.2.22/tokio/sync/struct.RwLock.html
D
ну короче идеальный вариант — для каждой задачи подбирать свой способ :))
D
и каналы — нифига не панацея, как некоторым кажется :))))))
A
Ну так и делают, вон тот же варп, в примерах лежал вебсокет чат, в начале он бвл на мютексах, потом переписали на rwlockи - вначале пишут чтобы работало, потом начинають тюнить, тот же parking lot в зависимостях стал появлятся куда не плюнь)
D
угу, я в общем-то такой же подход исповедую
V
типа вечные локи из-за непрекращающегося потока читателей
У паркинг лота рвлок вроде не даёт чтецам голодать
V
Емнип
D
Vetro
У паркинг лота рвлок вроде не даёт чтецам голодать
да, я ж скинул цитатку из их доки)