Копирую сюда полезные замечания из чата.
@kpp
хоть бенчи и самодельные, но вроде все ок: rust-lock-bench/src/lock_bench.rs at master · komamitsu/rust-lock-bench · GitHub
не хватает бенчей с crates.io: Rust Package Registry
@kpp
Ахах, parking_lot не особо помог)
==== num_reader: 20, num_writer: 0 ====
mutex => mean: 20.00, std_dev: 0.58
rwlock => mean: 57.29, std_dev: 1.25
prwlock => mean: 57.29, std_dev: 1.25
seq_cst => mean: 0.00, std_dev: 0.00
relaxed => mean: 0.00, std_dev: 0.00
unsync => mean: 0.00, std_dev: 0.00
==== num_reader: 0, num_writer: 20 ====
mutex => mean: 26.14, std_dev: 1.35
rwlock => mean: 115.14, std_dev: 4.91
prwlock => mean: 115.14, std_dev: 4.91
seq_cst => mean: 3.43, std_dev: 0.53
relaxed => mean: 3.86, std_dev: 0.38
unsync => mean: 0.29, std_dev: 0.49
один в один с std rwlock
@kurnevsky
@kpp parking_lot помимо производительности еще дает гарантии на то, что write lock будет рано или поздно получен, вне зависимости от интенсивности read локов.
@kpp
а обратное утверждение тоже верно?
@kurnevsky
В обратном мало смысла - write лок может быть один.
Он освобождает ресурс - следующий по очереди берет.
С read-ами сложнее - они могут браться непрерывно и освобождаться так, что ресурс никогда не будет свободен. Но при этом ни один лок сам по себе не берет ресурс навсегда.
То есть, write лок может висеть вечно.
Насколько помню, std такой гарантии не дает.
@kpp плюс еще зависит от бенчмарка. parking_lot может быть лучше, если лок берется несколько раз последовательно в одном треде.
(не смотрел этот конкретный бенчмарк)
@kpp
Кто хочет, может потестить komamitsu/rust-lock-bench#3
@kurnevsky
Интереснее потестить это совместно с токио
Потому как там локи могут залочить реактор целиком, несмотря на гринтреды.
И есть пару либ для локов в токио.