From: Yingxin Cheng Date: Mon, 15 Apr 2024 02:02:48 +0000 (+0800) Subject: crimson/common/tri_mutex: improve comments X-Git-Tag: testing/wip-mchangir-testing-20240429.064231-main-debug~9^2~2 X-Git-Url: http://git.apps.os.sepia.ceph.com/?a=commitdiff_plain;h=8eb9f0380f4328c672cbde9d3e1971b730695d73;p=ceph-ci.git crimson/common/tri_mutex: improve comments Signed-off-by: Yingxin Cheng --- diff --git a/src/crimson/common/tri_mutex.h b/src/crimson/common/tri_mutex.h index 369a8802cf0..a75895fa8de 100644 --- a/src/crimson/common/tri_mutex.h +++ b/src/crimson/common/tri_mutex.h @@ -47,11 +47,11 @@ public: /// shared/exclusive mutual exclusion /// -/// this lock design uses reader and writer is entirely and completely -/// independent of the conventional reader/writer lock usage. Here, what we -/// mean is that we can pipeline reads, and we can pipeline writes, but we -/// cannot allow a read while writes are in progress or a write while reads are -/// in progress. Any rmw operation is therefore exclusive. +/// Unlike reader/write lock, tri_mutex does not enforce the exclusive access +/// of write operations, on the contrary, multiple write operations are allowed +/// to hold the same tri_mutex at the same time. Here, what we mean is that we +/// can pipeline reads, and we can pipeline writes, but we cannot allow a read +/// while writes are in progress or a write while reads are in progress. /// /// tri_mutex is based on seastar::shared_mutex, but instead of two kinds of /// waiters, tri_mutex keeps track of three kinds of lock users: