On 13/03/2018, Sage Weil wrote: > Radoslaw noticed that the nlock field in common/Mutex.h was slowing > us down by 5% (and was basically useless). Also, all of the > conditional behavior based on constructor argumenst were fixed at > compile time. > > This points (again) at the fact that we have our own mutex wrapper > that we're using instead of std::mutex. Chatted a bit with Josh and > here is our thinking: > > - Someday we could replace our lockdep with helgrind, but there is a > lot of work needed to get there. This sounds wonderful! > - We could convert our Mutex class to conform to the c++ Mutex > concept. This mainly means renaming Lock -> lock, TryLock -> > try_lock, Unlock -> unlock. That would let us use things like > std::unique_lock<> and std::lock_guard<> with it. Cond would need a > similar makeover. I've already done this. I have common/mutex_debug that calls into lockdep and so forth, basically trying to be a conforming implementation analoous to Mutex So, (feel free to modify it, whatever to take out stuff we don't need) > - We can rename it (or alias it) to something like debug_mutex. > > - We can alias ceph::mutex to either std::mutex or ceph::debug_mutex > at compile time. Production builds can exclude our lockdep and use > std::mutex exclusively. Default dev/vstart builds can use > debug_mutex. Maybe notcmalloc flavor uses debug_mutex and default > flavor builds use std::mutex, so that we have both available for > teuthology tests. I think this sounds perfectly reasonable. > - All of our existing code can be converted to use ceph::mutex and > ceph::condition_variable instead of Mutex and Cond. > I think this ALSO sounds reasonable. We probably want to do something similar for RWLock. I don't know if we have any kind of lockdep analogue for read-write logs, but if we do I'd like to get rid of RWLock and use a ceph::shared_mutex instead. > - Profit! > > How does that sound? This sounds great and wonderful. -- Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US IRC: Aemerson@OFTC, Actinic@Freenode 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9 -- 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
