From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [PATCH] tools/memory-model: document the "one-time init" pattern Date: Mon, 27 Jul 2020 16:28:27 +0100 Message-ID: <20200727152827.GM23808@casper.infradead.org> References: <20200717044427.68747-1-ebiggers@kernel.org> <20200717174750.GQ12769@casper.infradead.org> <20200718013839.GD2183@sol.localdomain> <20200718021304.GS12769@casper.infradead.org> <20200718052818.GF2183@sol.localdomain> <20200727151746.GC1468275@rowland.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200727151746.GC1468275@rowland.harvard.edu> Sender: linux-kernel-owner@vger.kernel.org To: Alan Stern Cc: Eric Biggers , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, "Paul E . McKenney" , linux-fsdevel@vger.kernel.org, Akira Yokosawa , Andrea Parri , Boqun Feng , Daniel Lustig , "Darrick J . Wong" , Dave Chinner , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , Peter Zijlstra , Will Deacon List-Id: linux-arch.vger.kernel.org On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote: > Given a type "T", an object x of type pointer-to-T, and a function > "func" that takes various arguments and returns a pointer-to-T, the > accepted API for calling func once would be to create once_func() as > follows: > > T *once_func(T **ppt, args...) > { > static DEFINE_MUTEX(mut); > T *p; > > p = smp_load_acquire(ppt); /* Mild optimization */ > if (p) > return p; > > mutex_lock(mut); > p = smp_load_acquire(ppt); > if (!p) { > p = func(args...); > if (!IS_ERR_OR_NULL(p)) > smp_store_release(ppt, p); > } > mutex_unlock(mut); > return p; > } > > Users then would have to call once_func(&x, args...) and check the > result. Different x objects would constitute different "once" > domains. [...] > In fact, the only drawback I can think of is that because this relies > on a single mutex for all the different possible x's, it might lead to > locking conflicts (if func had to call once_func() recursively, for > example). In most reasonable situations such conflicts would not > arise. Another drawback for this approach relative to my get_foo() approach upthread is that, because we don't have compiler support, there's no enforcement that accesses to 'x' go through once_func(). My approach wraps accesses in a deliberately-opaque struct so you have to write some really ugly code to get at the raw value, and it's just easier to call get_foo(). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727784AbgG0P2s (ORCPT ); Mon, 27 Jul 2020 11:28:48 -0400 Date: Mon, 27 Jul 2020 16:28:27 +0100 From: Matthew Wilcox Subject: Re: [PATCH] tools/memory-model: document the "one-time init" pattern Message-ID: <20200727152827.GM23808@casper.infradead.org> References: <20200717044427.68747-1-ebiggers@kernel.org> <20200717174750.GQ12769@casper.infradead.org> <20200718013839.GD2183@sol.localdomain> <20200718021304.GS12769@casper.infradead.org> <20200718052818.GF2183@sol.localdomain> <20200727151746.GC1468275@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200727151746.GC1468275@rowland.harvard.edu> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Alan Stern Cc: Eric Biggers , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, "Paul E . McKenney" , linux-fsdevel@vger.kernel.org, Akira Yokosawa , Andrea Parri , Boqun Feng , Daniel Lustig , "Darrick J . Wong" , Dave Chinner , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , Peter Zijlstra , Will Deacon Message-ID: <20200727152827.gdhLiPr1UiOtyaY4FHaAAhCwB7bYCynolu5o1pK7MaA@z> On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote: > Given a type "T", an object x of type pointer-to-T, and a function > "func" that takes various arguments and returns a pointer-to-T, the > accepted API for calling func once would be to create once_func() as > follows: > > T *once_func(T **ppt, args...) > { > static DEFINE_MUTEX(mut); > T *p; > > p = smp_load_acquire(ppt); /* Mild optimization */ > if (p) > return p; > > mutex_lock(mut); > p = smp_load_acquire(ppt); > if (!p) { > p = func(args...); > if (!IS_ERR_OR_NULL(p)) > smp_store_release(ppt, p); > } > mutex_unlock(mut); > return p; > } > > Users then would have to call once_func(&x, args...) and check the > result. Different x objects would constitute different "once" > domains. [...] > In fact, the only drawback I can think of is that because this relies > on a single mutex for all the different possible x's, it might lead to > locking conflicts (if func had to call once_func() recursively, for > example). In most reasonable situations such conflicts would not > arise. Another drawback for this approach relative to my get_foo() approach upthread is that, because we don't have compiler support, there's no enforcement that accesses to 'x' go through once_func(). My approach wraps accesses in a deliberately-opaque struct so you have to write some really ugly code to get at the raw value, and it's just easier to call get_foo().