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 0B338A034C; Wed, 21 Dec 2022 17:37:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9FDB440A7F; Wed, 21 Dec 2022 17:37:22 +0100 (CET) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by mails.dpdk.org (Postfix) with ESMTP id E352A40A7A for ; Wed, 21 Dec 2022 17:37:20 +0100 (CET) Received: by mail-pf1-f172.google.com with SMTP id k79so11066713pfd.7 for ; Wed, 21 Dec 2022 08:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=cKLxnpvNUB1aqZGu7DLTtxKcquQQo3E7oF4nckFfoIQ=; b=UUdLhcOQJO3rrnu+kRUthNrdFZblIhdnOmpxuvQ/JvCEEP5sl7KFYN57M7BXcvGuJV qunUE7wooSxzm/0kUALnctbmVagXIJ2Sx7QY9Rb+jKyeVXVXAN5XdVkjENkG4ABj3pSN 7MpuwmyAisb55UT50LwV2E87jo/Pjjo9gwOi8FaQNGTNUeNMtGubrd9zX0iaNQ0FBzCC txT8gIz5af0Ze5B8ew3PcNT1iySFEQdFrYbwTVG6Oo/jpaL4bRwUOb5jmKCYtDSwn4r/ XJnIlsoQTyh9l/swMcJJ5vy90pDA2iw54afyS57EtPPOBw58l2JRG7U3bVX4Bv3YSStz vu+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cKLxnpvNUB1aqZGu7DLTtxKcquQQo3E7oF4nckFfoIQ=; b=tu/U9rB5Xj9WtfDYNzix+Cs1xwhGt73QFIaLlvHKMIx9oZyqyXFZkuBnepLPD82Q/y AYwiZSI4cvcCjbjLqGvFn4ER6qHobUTWXTyp3OQ07DXIhjuOpcQ/+IyCS/kXF57XGk78 DSKRqv+m5Um4rIVIRPI/veq7zSfEYt0lazOx9tqMCCbqvz3Mb9Uk0C+BURpO+2EXuGZS N/H5LkfndTHM8haWyegsItHbVKq5c2X11R0a67zSR/6/GHps7PaMCdys4/5RJp0aSsMd HCiRAE63xgpDNDoDvSIkHMxYjX1YMy3ZXzWG2219nO5WtLBkwUguS5ZL0ZmOB3X1K6ZF IvsA== X-Gm-Message-State: AFqh2kqGFSD9kAOoIvS3qdYJI8zK16u+/X4xdBtM05xuHC7kHJizyV8U y3oIYm48uidp/+CVd+Wu8CLSnw== X-Google-Smtp-Source: AMrXdXsfZNz785nAKU57FF54uiTuyCHzpdAklSd5ssMrF7QzcnOEjDeW+CA/HX1HLrRk2XJFmHH93A== X-Received: by 2002:a62:644b:0:b0:577:51b1:375e with SMTP id y72-20020a62644b000000b0057751b1375emr3261769pfb.26.1671640639913; Wed, 21 Dec 2022 08:37:19 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id h18-20020a056a00001200b005772f762e43sm11207685pfk.13.2022.12.21.08.37.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Dec 2022 08:37:19 -0800 (PST) Date: Wed, 21 Dec 2022 08:37:17 -0800 From: Stephen Hemminger To: "Zhou, Xiangyun" Cc: Konstantin Ananyev , Tyler Retzlaff , "dev@dpdk.org" , "Xu, Bowen" Subject: Re: C++20 report error at file rte_spinlock.h Message-ID: <20221221083717.135c3f81@hermes.local> In-Reply-To: References: <20221219163011.GA18921@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 20 Dec 2022 02:11:42 +0000 "Zhou, Xiangyun" wrote: > Thanks very much for Konstantin and Tyler's analyzing. > > I agree that removal of 'volatile' is enough. A spinlock has already used to protect these variables. > > -----Original Message----- > From: Konstantin Ananyev > Sent: Tuesday, December 20, 2022 12:51 AM > To: Tyler Retzlaff ; Zhou, Xiangyun > Cc: dev@dpdk.org; Xu, Bowen > Subject: RE: C++20 report error at file rte_spinlock.h > > > > On Tue, Dec 13, 2022 at 06:11:06AM +0000, Zhou, Xiangyun wrote: > > > Dear dpdk dev, > > > > > > I'm using dpdk 21.11 LTS, when compile my program with CPP flag > > > "-std=c++20", the compiler report below errors. After checking file > > rte_spinlock.h, I think the error report by compiler is valid, there > > should be a potential issue when using functions > > rte_spinlock_recursive_lock, rte_spinlock_recursive_unlock and > > rte_spinlock_recursive_trylock in multi-thread, we could either remove "volatile" definition to ask users to handle the multi-thread issue, or using atomic operatings instead of self-increment and self-decrement. > > > > > > > > > /home/dpdk/lib/eal/include/generic/rte_spinlock.h:221:12: error: > > > increment of object of volatile-qualified type 'volatile int' is > > deprecated [-Werror,-Wdeprecated-volatile] > > > slr->count++; > > > ^ > > > /home/dpdk/lib/eal/include/generic/rte_spinlock.h:231:6: error: > > > decrement of object of volatile-qualified type 'volatile int' is > > deprecated [-Werror,-Wdeprecated-volatile] > > > if (--(slr->count) == 0) { > > > ^ > > > /home/dpdk/lib/eal/include/generic/rte_spinlock.h:255:12: error: > > > increment of object of volatile-qualified type 'volatile int' is > > deprecated [-Werror,-Wdeprecated-volatile] > > > slr->count++; > > > > > > > i have work in progress to optionally use standard atomics but in the > > meantime the correct thing to do here is to use the gcc builtins that > > match the requirements of the c++11 memory model. > > > > the code should be converted to use __atomic_fetch_{add,sub} or > > __atomic_{add,sub}_fetch as appropriate. > > > > ty. > > From looking at the code, I don't think it is necessary: > both 'user' and 'count' supposed to be protected by 'sl'. > In fact, it looks safe just to remove 'volatile' qualifier here. > > I noticed a couple of other documentation errors here. The intro comment says this a read-write lock (and it isn't). Probably copy/paste error. The user field says is is "core id" but it really is thread id.