On Tue, Mar 13, 2018 at 2:16 PM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > On Tue, Mar 13, 2018 at 2:04 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> On Tue, 13 Mar 2018, Jesse Williamson wrote: >>> On Tue, 13 Mar 2018, Gregory Farnum wrote: >>> >>> > Otherwise, this sounds like a fine idea to me. Trying to unify these >>> > behaviors from a code style perspective is long overdue given our >>> > other modernization efforts. :) >>> >>> Total agreement-- and, FWIW, /besides/ lockdep, every single Mutex and Cond >>> call can absolutely be replaced with the C++ standard library at this point. >> >> I think one wrinkle is that we have lots of lines like >> >> assert(lock.is_locked_by_me()); >> >> sprinkled about, usually at the top of internal _foo() methods. I don't >> think there is a std::mutex equivalent (that operates on the mutex itself >> and not a std::unique_lock). >> >> I'm not sure if it's worth trying to keep something like this around for >> the debug_mutex... I think we'd need to create some sort of macro >> like ASSERT_MUTEX_LOCKED(lock) that compiles away to nothing in the >> std::mutex case? > > Oooo, yeah. So there are *quick grep* 66 of those. In the Objecter, we > pretty much wrap everything in a unique_lock, pass that through the > function call chains, and make use of the "owns_lock" functionality. > unique_lock is mostly analogous to our Locker but not quite (you can > lock and unlock through it) and might be a simpler way to swap it in > on a per-thread basis, if we wanted to get gross. (Or do the same > thing as Objecter where we force you to pass a unique_lock in to all > of those internal functions; I think they mostly only assert in cases > where they're going to change the lock state? So it might be good prep > work for stuff like the MDS going multi-lock anyway.) > > Straight-up losing that safety check without replacement would be a > bit sad. Not sure it's worth holding anything up for or not, though. More than sad. It's a useful debugging and development tool. The Objecter code where it was used extensively is a good example for when it was really useful for validating the correctness of a large-ish code refactoring work. Yehuda > -Greg > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
