On Fri, Mar 16, 2018 at 11:30 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > I think all of this is secondary (and mostly doesn't matter)... the *real* > win will be using std::mutex instead of ceph::debugging_mutex. It > almost doesn't matter how slow debugging_mutex is. Having fast debug > builds is nice, but let's not get distracted from the real prize! Yeah, a std::string in debug_mutex is a sidequest. Having the possibility to differentiate basing on build type (that would affect lockdep as well as mutex_perf_counter) makes clean wrapper over standard mutex a way to go. Alignment is a different story. AFAIK the language doesn't impose anything special for std::mutex. This puts into consideration the method of aliasing for ceph::mutex as having it powerful enough (while preserving the zero run-time overhead!) to convey things like `alignas()` seems worthwhile. Direct typedef/macro to std::mutex isn't an option even because of the difference in ctor's arguments in respect to debug_mutex. Thin class (ceph::production_mutex?) wrapping std::mutex would allow for e.g. `alignas()` and offer potential for interface tuning (e.g. facilities for asserts verifying lock status) and implementation (like going directly to pthread in some cases or just selecting the std::recursive_mutex kind). This could impose a mechanism for compile-time hints. For sure we'll have recursive and non-recursive ones but more labels (adaptive, lock eliding?) might appear in the future. Embedding such things into types would lead to e.g. ceph::mutex<flags::recursive::eliding>, possibly with extra sugar like ceph::recursive_mutex. Regards, Radek -- 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
