masaori335 commented on code in PR #13310:
URL: https://github.com/apache/trafficserver/pull/13310#discussion_r3457643757
##########
include/tsutil/TsSharedMutex.h:
##########
@@ -178,6 +184,38 @@ class shared_mutex
X(std::atomic<int> _shared{0};)
};
+// RAII guards for ts::shared_mutex that carry Clang thread-safety capability
+// state. Prefer these over std::unique_lock / std::shared_lock in code
annotated
+// for -Wthread-safety: the analysis does not reliably track the std wrappers
+// (see tsutil/ts_thread_safety.h).
Review Comment:
The renaming from `std::unique_lock/std::shared_lock` to
`ts::scoped_writer_lock/ts::scoped_reader_lock` is explicitly telling that it's
adding thread-safety capability but losing flexibility?
I thought we should name them `ts:unique_lock/ts::shared_lock` but Claude
pointed out below.
> std::unique_lock/std::shared_lock are the flexible wrappers: movable,
deferrable (std::defer_lock), .unlock()/.lock()/.release()/adopt. The ts::
versions are deliberately rigid — acquire-in-ctor, release-in-dtor,
non-movable, no manual unlock. Someone who writes ts::unique_lock l(m); …;
l.unlock(); (valid on std::unique_lock) gets a compile error. The name
advertises flexibility the type doesn't have.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
