On 13/03/2018, Gregory Farnum wrote: > 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 My thought is we probably don't really /need/ these checks. If we /want/ them, especially in places like Objecter where there's One Lock per Class, we should do them statically. This is fairly easy to do in the type system if a bit fiddly. The big downside is we'd be replacing unique_lock shared_lock with magical template Foo. -- 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
