Details
- Reviewers
ldionne Mordante • Quuxplusone - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/src/debug.cpp | ||
---|---|---|
73 | This is great RAII cleanup! Throughout, I think we should stay away from the identifier _ because people (GNU gettext, C++ pattern-matching proposals, ...) like to mess with it. In other codebases, my convention is std::lock_guard lk(m); i.e. using lk as the name of the lock variable. Of course guard also seems like a good name. ;) | |
263–293 | This smells like you need db_guard to be .release()-able, so that you can eliminate all of the #if-stuff and manual unlocking currently here, and just do guard.release(); // Keep the write lock locked when we return non-null return p; on line 294. (Write lock? Read lock? I didn't look closely enough.) |
Address reveiw comments
libcxx/src/debug.cpp | ||
---|---|---|
73 |
Having separate structs for read and write locks to me would indicate that there was some need to separate them - e.g. a subtle difference in behaviour somehow, or at the very least the behaviour is likely to diverge in the future in a way that will be hard to implement retroactively if we don't keep them separate now. Neither of these is the case here, and IMO separating them sends the wrong message. It also feels akin to premature optimization - extra work done to solve a non-existent problem. | |
263–293 | I'd considered that, but wasn't sure if it was worth it. I've changed it now though. |
libcxx/src/debug.cpp | ||
---|---|---|
69 | ||
73 |
FWIW, my intuition is basically that exact thing you said; the "hard" part is merely that the future programmer will have to figure out which of the mutex locks are "locking for reading" and which are "locking for writing," and then every code-reviewer on their review will have to check their work. We've already done the work (I assume), so I think we should keep it. (And keeping it as code makes more sense than keeping it as comments, even if the code is tantamount to comments anyway.) using db_read_guard = db_guard; using db_write_guard = db_guard; Pay 3 lines of code, to save 15 lines of comments. Worth it IMO. | |
78 | ||
263–293 | So worth it. :) |