On Fri, 12 Dec 2025 at 10:59, Peter Zijlstra <[email protected]> wrote: > > On Thu, Dec 11, 2025 at 02:24:57PM +0100, Marco Elver wrote: > > > > It is *NOT* (as the clang naming suggests) an assertion of holding the > > > lock (which is requires_ctx), but rather an annotation that forces the > > > ctx to be considered held. > > > > Noted. I'll add some appropriate wording above the > > __assumes_ctx_guard() attribute, so this is not lost in the commit > > logs. > > On IRC you stated: > > <melver> peterz: 'assume' just forces the compiler to think something is > held, whether or not it is then becomes the programmer's problem. we > need it in 2 places at least: for the runtime assertions (to help > patterns beyond the compiler's static reasoning abilities), and for > initialization (so we can access guarded variables right after > initialization; nobody should hold the lock yet) > > I'm really not much a fan of that init hack either ;-) > > Once we get the scope crap working sanely, I would much rather we move > to something like: > > scoped_guard (spinlock_init, &foo->lock) { > // init foo fields > } > > or perhaps: > > guard(mutex_init)(&bar->lock); > // init until end of current scope > > Where this latter form is very similar to the current semantics where > mutex_init() will implicitly 'leak' the holding of the lock. But the > former gives more control where we need it.
I like it. It would also more clearly denote where initialization start+ends if not confined to a dedicated function.
