From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2CBCF439D6; Fri, 26 Jan 2024 22:03:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7E75F402AB; Fri, 26 Jan 2024 22:03:14 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 3BC5A40289 for ; Fri, 26 Jan 2024 22:03:13 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 7C10120E61A1; Fri, 26 Jan 2024 13:03:12 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7C10120E61A1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1706302992; bh=BMVY9gnnVOuzGfCDadfSqhA6aCqlnvxEtExRqOU1Of4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Cl+RyDpmF522diP++GSeZTjF0QetwvfTVArX5S6HmpT/JRyQYCof5u45ndCRlRD5t ufunhAlUSa0Qh5aUZplLuRNFEG7ZkEU9dYERreUaCTadaYunp2N4zb3Oy7kcGZfyte 1dOuPjLyOffGdsCSdhz0HnmnQ7pGuhzmnLpv18fU= Date: Fri, 26 Jan 2024 13:03:12 -0800 From: Tyler Retzlaff To: Honnappa Nagarahalli Cc: Mattias =?iso-8859-1?Q?R=F6nnblom?= , Morten =?iso-8859-1?Q?Br=F8rup?= , "dev@dpdk.org" , Tyler Retzlaff , "konstantin.v.ananyev@yandex.ru" , nd , Mattias =?iso-8859-1?Q?R=F6nnblom?= Subject: Re: rte_atomic_*_explicit Message-ID: <20240126210312.GA22822@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <0e268757-8368-456f-ba2f-10a1969c498f@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F1A2@smartserver.smartshare.dk> <20240125223438.GA22922@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <97893aa5-4e13-4761-9fcb-214b3819bc16@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Jan 26, 2024 at 04:58:54PM +0000, Honnappa Nagarahalli wrote: > > > > > > > >> > > >> On Thu, Jan 25, 2024 at 11:10:47PM +0100, Morten Br�rup wrote: > > >>>> From: Mattias R�nnblom [mailto:hofors@lysator.liu.se] > > >>>> Sent: Thursday, 25 January 2024 19.54 > > >>>> > > >>>> Why do rte_stdatomic.h functions have the suffix "_explicit"? > > >>>> Especially > > >>>> since there aren't any wrappers for the implicit variants. > > >>>> > > >>>> More to type, more to read. > > >>> > > >>> They have the "_explicit" suffix to make their names similar to > > >>> those in > > >> stdatomic.h. > > >>> > > >>> You might consider their existence somewhat temporary until C11 > > >>> stdatomics > > >> can be fully phased in, so there's another argument for similar > > >> names. (This probably does not happen as long as compilers generate > > >> slower code for C11 stdatomics than with their atomic built-ins.) > > >> > > >> yes, there was feedback at the time it was. > > >> > > >> * we should *not* have non-explicit versions of the macros > > >> * the atomic generic functions should be named to match C11 standard > > >> with a rte_ prefix. > > > This was mainly done to ensure that users think through the memory > > ordering they want to use. This also matches with the compiler atomic built- > > ins. Without explicit, it is sequentially consistent memory order. > > > > > > > "This" is referring to the first bullet only, correct? > > > > You don't have to distinguish between implicit and explicit if you only have > > explicit. > Agree on your thought. > > The '_explicit' was added to be aligned with the standard atomic API naming. The thought was - if we are aligned on the names, it needs less explanation for users. well another benefit is that in the future if/when a decision is made to directly use the names from the standard it is most trivial to just strip the rte_ prefix tree wide.