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. -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
