From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7B96FC27C6E for ; Sat, 15 Jun 2024 02:46:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OT2RssNaSUa1rWMkNzd+1pQBqOCAu8315Wi2zKuipi0=; b=C09sDru+cvJEQKQBf9cFR35cC/ e0HC6XUMfx7eHWZuRckXBkWWAozG65WEB5IHPQMI5z9sAIGZF1DJVr3pwc9ZxtvBISiyKesfJRzlw xZdaShKgcUUQK8hS0+fSpBBrvKJY0X7YMI1io0hlhFdaU++ycz4pj1SBeGAYqOoNQrIqzc/ors3kQ YBqRLwZmutdPgYlTNIRXOoUgu07BilJKuZykMobbFWGAP/scKc4Owk1LkK4Cv4pFiqGyU2kDIzf86 Ny+2CZg1ulo+xBKXUAxKLURVRZ55AlrXFkrKTcRnayOWv4hLSR4jlEA75w5wVFsvHy5u3T3gHk7Jg JwS3MkoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sIJQv-00000004Vpy-3B2L; Sat, 15 Jun 2024 02:46:25 +0000 Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sIJQr-00000004Vnh-3itJ for linux-arm-kernel@lists.infradead.org; Sat, 15 Jun 2024 02:46:24 +0000 Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-44056295c8cso14096611cf.3 for ; Fri, 14 Jun 2024 19:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718419578; x=1719024378; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:from:to:cc:subject:date:message-id:reply-to; bh=OT2RssNaSUa1rWMkNzd+1pQBqOCAu8315Wi2zKuipi0=; b=K0/yL1C93RW8XmetJz5IEcP+lweP7s8of0Xg+FzTOoAkOjEDrGDYkaHWTaHTzxcxp9 3vRhiG+f4Zk0IL0h6ZxGOznixh1CCJUgfd0yTqtmXBCCDSSFZpGlTk3KBCZssOLjyeyQ 0o69M2zZ6gvrbfsv8FetCt/dzolIO/gCtwaPtzXE8DaDdqzj2/Ck5aa4+eJSALPRnBnY CIB98meyaDlUzlwQQ/7J6dFWODJEHjxOrrKxbCILNVOkxQaY0775ol4eWoU8ij1VYSPZ cDyKmYRcQS/ni3910SkNLdG+kou5Px3+ABbE+LYh02uYJLISY5Bf+5QzaCtl7lhT5ACY AvVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718419578; x=1719024378; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OT2RssNaSUa1rWMkNzd+1pQBqOCAu8315Wi2zKuipi0=; b=AA+q9dCX+vub12lr9cuMxXlLln9wLL20KzvEFfGx1aWi9Mam+WTsZIJBerKQoAQIDS IoOVz2Jdkq9Gn+bpqcyx5xgMHy8t3tzzN2zOQrEECXBv1hPHtj8f6IqGB+p/bdsBSwcL 7osK6bgZuFiPyBBcQhA8s6SGgzmDOHH59mZFTi/1al8OJnppR17YKAfICPHhUKlapZE9 L/tP9jbsSAJ0u7USg14NVxTPKdtuvnYDtldSzMwMvqXiijoTpzwdae9IXm24XGNnMqPf GEZWFkvASvaNZAVjJCa+LxjFklJ7iFF6ECR83odI5osx6bQD9rJ+2BS1Eib7+LBliyJY fe9g== X-Forwarded-Encrypted: i=1; AJvYcCVjVMncgFTGSknQZNWyB87po8/sB4qi2jzFVao9kbWC3/4Gr38ko3Tdy6t5SVPdyYPENCzJmv3XfdnM0Y4kRdLwbUZ468eoNwvlxc8I2o3RqRulGEc= X-Gm-Message-State: AOJu0Yy9UP4lU5FPNS95FLui8Wvn+e5f2mWfT9QymadvaCAoebWtYB4k SLeyswzoSBmx4b14ytR61g2a4OV6WJfnOe9wHhoGQskc5DJl3RLb X-Google-Smtp-Source: AGHT+IG3nzFdI5+53c3/xvx6gEm8fdTfMr49LEKpg9JdpL+E4lnmp5VenTGHRK+8HEy1H5IpoWTJsA== X-Received: by 2002:a05:622a:3cf:b0:441:1536:2fb2 with SMTP id d75a77b69052e-442168fc2a2mr45239521cf.5.1718419577401; Fri, 14 Jun 2024 19:46:17 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-441ef4fe986sm22655881cf.33.2024.06.14.19.46.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jun 2024 19:46:17 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id CAF0C120006A; Fri, 14 Jun 2024 22:39:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 14 Jun 2024 22:39:30 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvtddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepgffgheejtdfhheehtdejffehgedujeekudfgieejledttedvvdeiuefg fedvffdvnecuffhomhgrihhnpegtrhgrthgvshdrihhonecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunh drfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Jun 2024 22:39:29 -0400 (EDT) Date: Fri, 14 Jun 2024 19:39:27 -0700 From: Boqun Feng To: John Hubbard Cc: Miguel Ojeda , Gary Guo , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , kent.overstreet@gmail.com, Greg Kroah-Hartman , elver@google.com, Mark Rutland , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Catalin Marinas , torvalds@linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, Trevor Gross , dakr@redhat.com Subject: Re: [RFC 2/2] rust: sync: Add atomic support Message-ID: References: <20240612223025.1158537-1-boqun.feng@gmail.com> <20240612223025.1158537-3-boqun.feng@gmail.com> <20240613144432.77711a3a@eugeo> <79239550-dd6e-4738-acea-e7df50176487@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240614_194621_942111_B0C2C238 X-CRM114-Status: GOOD ( 37.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 14, 2024 at 06:28:00PM -0700, John Hubbard wrote: > On 6/14/24 6:24 PM, Boqun Feng wrote: > > On Fri, Jun 14, 2024 at 06:03:37PM -0700, John Hubbard wrote: > > > On 6/14/24 2:59 AM, Miguel Ojeda wrote: > > > > On Thu, Jun 13, 2024 at 9:05 PM Boqun Feng wrote: > > > > > > > > > > Does this make sense? > > > > > > > > Implementation-wise, if you think it is simpler or more clear/elegant > > > > to have the extra lower level layer, then that sounds fine. > > > > > > > > However, I was mainly talking about what we would eventually expose to > > > > users, i.e. do we want to provide `Atomic` to begin with? If yes, > > > > then we could make the lower layer private already. > > > > > > > > We can defer that extra layer/work if needed even if we go for > > > > `Atomic`, but it would be nice to understand if we have consensus > > > > for an eventual user-facing API, or if someone has any other opinion > > > > or concerns on one vs. the other. > > > > > > Well, here's one: > > > > > > The reason that we have things like atomic64_read() in the C code is > > > because C doesn't have generics. > > > > > > In Rust, we should simply move directly to Atomic, as there are, > > > after all, associated benefits. And it's very easy to see the connection > > > > What are the associated benefits you are referring to? Rust std doesn't > > use Atomic, that somewhat proves that we don't need it. > Just the stock things that a generic provides: less duplicated code, It's still a bit handwavy, sorry. Admittedly, I haven't looked into too much Rust concurrent code, maybe it's even true for C code ;-) So I took a look at the crate that Gary mentioned (the one provides generic atomic APIs): https://crates.io/crates/atomic there's a "Dependent" tab where you can see the other crates that depends on it. With a quick look, I haven't found any Rust concurrent project I'm aware of (no crossbeam, no tokio, no futures). On the other hand, there is a non-generic based atomic library: https://crates.io/crates/portable-atomic which has more projects depend on it, and there are some Rust concurrent projects that I'm aware of: futures, async-task etc. Note that people can get the non-generic based atomic API from Rust std library, and the "portable-atomic" crate is only 2-year old, while "atomic" crate is 8-year old. More interestingly, the same author of "atomic" crate, who is an expert in concurrent areas, has another project (there are a lot projects from the author, but this is the one I'm mostly aware of) "parking_lot", which "provides implementations of Mutex, RwLock, Condvar and Once that are smaller, faster and more flexible than those in the Rust standard library, as well as a ReentrantMutex type which supports recursive locking.", and it doesn't use the "atomic" crate either. These data could mean nothing, there are multiple reasons affecting the popularity of a library. But all the above seems to suggests that you don't really need generic on atomic, at least for a lot of meaningful concurent code. So if we were to make a decision right now, I don't see that generic atomics are winning. Of course, as I said previously, we can always add them if we have learned more and have the consensus. (Don't make me wrong, I love generic in general, I just want to avoid the "I have a generic hammer and everything looks like generic nails" situation.) Regards, Boqun > automatic support for future types (although here it's really just > integer types we care about of course). > > > thanks, > -- > John Hubbard > NVIDIA >