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 ACDDBC27C53 for ; Sun, 16 Jun 2024 15:06:32 +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=VqObIqQp+WLPy3VVCqeSeRx29NarkCBbux5QQu76V4Y=; b=o238fqd4qRVNRwJFmfo9vzzjsi w84Q1CiD9GqSt/nAvMfmUwBp7g8yUgdpoV8cqv0dV16J9gB7BxVkHJlIrhOr1abNhMdAQAysQmb+d IXic5oBXWU5RbYmuWBpw3oecPRo2n4rNEKyDcgyZHOjweKo3cDIpuZWeZt5x8B+nZ9u1DYw8iQjsJ lhfPTfnxGmBHHmkO3aLSj/Dua4A/dAP7EUPKssC6BvLG9E3/DLzEp+DI5GAz4kF2HjOBFIBOrnUTq Hxd40tV8feiSuO8vdQoVrA/MdG+4SFce/iViDAJMups6miyVUbyRXVlmfk4jUrCCyT9+apnn8PvK/ YVV/kJlw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sIrSP-00000007k8Q-0REr; Sun, 16 Jun 2024 15:06:13 +0000 Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sIrSM-00000007k7Q-06ex for linux-arm-kernel@lists.infradead.org; Sun, 16 Jun 2024 15:06:11 +0000 Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-6ad8243dba8so18538366d6.3 for ; Sun, 16 Jun 2024 08:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718550369; x=1719155169; 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=VqObIqQp+WLPy3VVCqeSeRx29NarkCBbux5QQu76V4Y=; b=e8qJLH0mgrcbAuihq3OLCipoGNch07eeLeaiR4TEq/DzLWjZVXPnzzTtwfP3idX8DI mK9k7Hx93MzM56J68isKHxp18CHtzKwfaPEMv3JCES0jXF6r7UgUI6RON9xl8QnxQjI7 xACN/BA1adja8/xdPSZgpT9QqMNjDotthgZ7Kdr6Dfr5IR1WVO8ZnHyRUCpeIkGYXc3r 8yJRWthguQxbJPhbJtJamhas3NuXzYGM9Vp+G19QRUZ0RZnNnk+2Zivt+U7hlVDe5MSN 2B3Rlx4rJ428XhzxGfhHny0cqyaxJ4uSaaTJSmD7UGwZg9U8n8ZcFcXZ8sBB+JIJR7D5 llVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718550369; x=1719155169; 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=VqObIqQp+WLPy3VVCqeSeRx29NarkCBbux5QQu76V4Y=; b=eGC4TBaglszdvXlAtlLY76EGVOs2bpWIg86F76WEsVjFC3Vw5L3hqtmuGFUKSZArAH J7cEDQof70S13rn4vFqRUkJMz00KHyoj73f+aMlEuqx8jyABZWN3j9Fn8g7rsVAa1Hxw kkW2dq7L5FCawNrmuoAfFHkY48LDk+Aa/ILHBKogZg8VJW5TJvl8nJTV+CiQIiyc+tnm g87ls5VgZWe/YxsOYNHIc2hujww0lEz5jkfpV/UTQtxjo9bJej6HfKZq7Hao0W152ZJJ ajy/z6JLl7DQ8ngoF9u5oN9qi2Ywm/Bq+5YyWSsKif1FLm4FtkCtICIzJwNFNM5r2YLb Cn1A== X-Forwarded-Encrypted: i=1; AJvYcCVeuNoTcLNVdBeKm3YeenovEqLJ9cuwPlrWG+FOGqfaBaKidISPFh50duawLKdg8yHWaW7JMEm8WPckX2hAXtuNXwaQ6ZkWpG7kWIUlTHE1qCP68zg= X-Gm-Message-State: AOJu0YzeymVvTEllaAxO62zF3GYj0foq7/0mEeNfsEOohTMl6tv8XJgw DYBhnZJ/kMdWpkglgYF4W8ckfadjfFf5UfKJNETWlVBoPiuRzwQs X-Google-Smtp-Source: AGHT+IGBNIQC6j0BqwcDzH3wRTTRHzh/QPcr+NqgMAY2KJ5ds6X+rg2sPyjML9quC4pDD9ZSVedEYg== X-Received: by 2002:ad4:4ea9:0:b0:6b0:8f42:2435 with SMTP id 6a1803df08f44-6b2afd6a451mr116202186d6.51.1718550368805; Sun, 16 Jun 2024 08:06:08 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b2a5bf2879sm44716896d6.21.2024.06.16.08.06.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jun 2024 08:06:08 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id 3E0C61200043; Sun, 16 Jun 2024 11:06:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 16 Jun 2024 11:06:07 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvfedgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepgffgheejtdfhheehtdejffehgedujeekudfgieejledttedvvdeiuefg fedvffdvnecuffhomhgrihhnpegtrhgrthgvshdrihhonecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunh drfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 16 Jun 2024 11:06:06 -0400 (EDT) Date: Sun, 16 Jun 2024 08:06:05 -0700 From: Boqun Feng To: Gary Guo Cc: John Hubbard , Miguel Ojeda , 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: <20240613144432.77711a3a@eugeo> <79239550-dd6e-4738-acea-e7df50176487@nvidia.com> <20240616155145.54371240.gary@garyguo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240616155145.54371240.gary@garyguo.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240616_080610_099885_AF1BDCCB X-CRM114-Status: GOOD ( 50.51 ) 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 Sun, Jun 16, 2024 at 03:51:45PM +0100, Gary Guo wrote: > On Fri, 14 Jun 2024 19:39:27 -0700 > Boqun Feng wrote: > > > 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. > > Note that crossbeam's AtomicCell is also generic, and crossbeam is used > by tons of crates. As Miguel mentioned, I think it's very likely that in > the future we want be able to do atomics on new types (e.g. for > seqlocks perhaps). We probably don't need the non-lock-free fallback of Good, another design bit, thank you! What's our overall idea on sub-word types, like Atomic and Atomic, do we plan to say no to them, or they could have a limited APIs? IIUC, some operations on them are relatively sub-optimal on some architectures, supporting the same set of API as i32 and i64 is probably a bad idea. Another thing in my mind is making `Atomic` pub struct Atomic { ... } so that `Atomic` will always be `Sync`, because quite frankly, an atomic type that cannot `Sync` is pointless. Regards, Boqun > crossbeam's AtomicCell, but the lock-free subset with newtype support > is desirable. > > People in general don't use the `atomic` crate because it provides no > additional feature compared to the standard library. But it doesn't > really mean that the standard library's atomic design is good. > > People decided to use AtomicT and NonZeroT instead of Atomic or > NonZero long time ago, but many now thinks the decision was bad. > Introduction of NonZero is a good example of it. NonZeroT are now > all type aliases of NonZero. > > I also don't see any downside in using generics. We can provide type > aliases so people can use `AtomicI32` and `AtomicI64` when they want > their code to be compatible with userspace Rust can still do so. > > `Atomic` is also just aesthetically better than `AtomicI32` IMO. > When all other types look like `NonZero`, `Wrapping`, I don't > think we should have `AtomicI32` just because "it's done this way in > Rust std". Our alloc already deviates a lot from Rust std. > > Best, > Gary