On Fri, 16 Mar 2018, Radoslaw Zarzynski wrote: Hi Radoslaw, First of all, very interesting analysis!
Looks interesting. What about making the developer's choice compile-time? I haven't poked with RWLock but during the Mutex pacification there was no Mutex usage that overrides the default- valued parameters in a way that is truly run-time dependent.
There are only a couple of cases that are recursive, or that fiddle with lockdep. Nearly all instances are non-recursive, lockdep-enabled, no-backtrace.
Agreed, none that I remember do anything different after the point they're constructed, there's no reason for the runtime behavior that I can see.
This gives also a chance to differentiating policies basing on build type (production, development). As somebody already pointed out, C++17 improves things with if constexpr().
Yeah. I've broken up the implementations into two classes, BasicMutex and RecursiveMutex, but this was just an experiement to identify the actual roles of each Mutex. The SFINAE work to do this concisely is now pretty straightforward with constexpr-if.
I have several things in-progress right now, but I'm happy to revisit this if there's interest.
-Jesse -- 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
