From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150083.outbound.protection.outlook.com [40.107.15.83]) by dpdk.org (Postfix) with ESMTP id C24CC1B4D1 for ; Wed, 19 Dec 2018 16:11:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wwwRUSveqPBHdapQ1cuWsrFEx+qprDbkd6zK4g03Ivs=; b=o1nvG9bwbl/4olDeVR2Bs6hoilDZTZFag6n5MTsxwn58nrc+QIixPlgYMxr50lSn5AJrv9s5tzu7llEEx1HuP76S2bEsLOSreDK/B2YpI97nhZljDVWWF8oVqlFyuqe3zEPwSDQQctNB256FMUZh7l7DJs4TTvvdAPzd3GEqi1g= Received: from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.29) by AM6PR08MB3927.eurprd08.prod.outlook.com (20.178.87.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Wed, 19 Dec 2018 15:11:22 +0000 Received: from AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::78ab:2bf4:5476:6c3e]) by AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::78ab:2bf4:5476:6c3e%2]) with mapi id 15.20.1446.018; Wed, 19 Dec 2018 15:11:22 +0000 From: Honnappa Nagarahalli To: Konstantin Ananyev , "dev@dpdk.org" CC: nd , "Gavin Hu (Arm Technology China)" , nd Thread-Topic: [dpdk-dev] [PATCH 1/2] rwlock: introduce 'try' semantics for RD and WR locking Thread-Index: AQHUe3Y4LNv3q8oKTkmfFHzLgY5Wn6WFyidQgACUVTA= Date: Wed, 19 Dec 2018 15:11:22 +0000 Message-ID: References: <1542130061-3702-1-git-send-email-konstantin.ananyev@intel.com> <1542130061-3702-2-git-send-email-konstantin.ananyev@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.103.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR08MB3927; 6:JWVLgMNxe8G2EbDvMu0MUwOfC1djNyAO7FkGEwfuZPUya/LaIxtbVgHgDVlgL0EIrRc6I28yz2vP/dlVL6JAFA1BcESZe/+Tktx1Z7POHQ95hQYQ7H1v1jHYuEPGT4eENUbnzh4vka2nmauMxde1JkK989ORjVhK7qRPRqGjdB4BqNMamLFAnLgTi12zX6Rdju1+nJQV5Q0AT7R8Ocm7IDbwK+KT89FyWsuf+DSsVXMSpQvw6q4xXFyIDXcklhf7Dea2Hwc8gu8q95WGCzwXrH2b3h6RUXfDaBQyRseO+t0dERBrsYSVWYvkmceXJQ/sz6p27jmHfJYZ9DI3qUesJlM/SAYudCOWI90m5mJzJWtrToKwCXKzR8dYpX/vZMlV9RUy7FSsaPy6z2Jw6t0LL/GcHfwTtcQgXZJeLcSsWKMTpJjp8yPfzlVp5ckwuH9czvSiSz2A3hfRP+nfJZtjxw==; 5:/bIboi3rion7HBS2ru6ujI2wd6suz+zMepm2THcFCGkUY47cjK/5sgDZSyy/9jd93BQHyYTMrQvcmyHocCEiFsDpGblOUfSWpA1Ggbi52RkR1F1h+9WxJrA9E3I9pqRSaKBbMBWHgYazVSTkZa8nyaBJD9TOyJz3etdRENX/+eY=; 7:WNyJNJBkCgE6yqAEe/3uufzshEOnpmwu/cJ3MSzffdAitKNYLG4W8J3dFiibKnJMIsQOgVsxdlo2uwDG57Ke7vkM2GKoUmXDts5cTFe2/Xm1yClu7qCgkt58hMt+31QygdFcZCQalk+IsVsxxZHS2Q== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-correlation-id: 95d51fe8-fea4-493e-af1d-08d665c43c7b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR08MB3927; x-ms-traffictypediagnostic: AM6PR08MB3927: nodisclaimer: True x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231475)(944501520)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM6PR08MB3927; BCL:0; PCL:0; RULEID:; SRVR:AM6PR08MB3927; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(396003)(136003)(39860400002)(199004)(189003)(81166006)(14454004)(2501003)(97736004)(8936002)(81156014)(105586002)(229853002)(6436002)(11346002)(305945005)(446003)(14444005)(486006)(74316002)(7736002)(476003)(2940100002)(2906002)(256004)(5660300001)(6506007)(76176011)(7696005)(186003)(6246003)(26005)(106356001)(4326008)(9686003)(102836004)(53936002)(3846002)(6116002)(66066001)(68736007)(575784001)(86362001)(316002)(33656002)(54906003)(110136005)(25786009)(99286004)(71200400001)(71190400001)(93156006)(55016002)(478600001)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3927; H:AM6PR08MB3672.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dY+OMCGFmY4LHBuATcbG1pnorXbvqK4Gn3QVmXr+sSgKwGfvdwMDSsQucQdUpyOkOZFiyDg/MxeeNETA04zCCHHhswJGH5z/NR8pcld3tjIjai9MEIrKuqICKGDZ7CjSivPj1hmJsyR3wOUN+j/30JIeClnGgvvycZmkhVPaU0mjV+2MURbrMG82KtMRBoXTsrJgd/5TWlvwdfoRgew5Tgl5PX33UmlYFlCB55P/6/6VdPsAB/rc2j5HZUJ/2NgtVtdtSDj1JVz+EasCJVBa2QNqiIveqRcFcwP0Mkz+lCbVl4OGIenfjKsGKg2jTyC3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95d51fe8-fea4-493e-af1d-08d665c43c7b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 15:11:22.1637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3927 Subject: Re: [dpdk-dev] [PATCH 1/2] rwlock: introduce 'try' semantics for RD and WR locking X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 15:11:24 -0000 >=20 > > > > This patch targets 19.02 release. > > > > Introduce rte_rwlock_read_trylock() and rte_rwlock_write_trylock(). > > Signed-off-by: Konstantin Ananyev > > --- > > .../common/include/generic/rte_rwlock.h | 54 +++++++++++++++++++ > > lib/librte_eal/rte_eal_version.map | 2 + > > 2 files changed, 56 insertions(+) > > > > diff --git a/lib/librte_eal/common/include/generic/rte_rwlock.h > > b/lib/librte_eal/common/include/generic/rte_rwlock.h > > index 5751a0e6d..7e395781e 100644 > > --- a/lib/librte_eal/common/include/generic/rte_rwlock.h > > +++ b/lib/librte_eal/common/include/generic/rte_rwlock.h > > @@ -75,6 +75,33 @@ rte_rwlock_read_lock(rte_rwlock_t *rwl) > > } > > } > > > > +/** > Please add the experimental API warning >=20 > > + * try to take a read lock. > > + * > > + * @param rwl > > + * A pointer to a rwlock structure. > > + * @return > > + * - zero if the lock is successfully taken > > + * - -EBUSY if lock could not be acquired for reading because a > > + * writer holds the lock > > + */ > > +static inline __rte_experimental int > > +rte_rwlock_read_trylock(rte_rwlock_t *rwl) { > > + int32_t x; > > + int success =3D 0; > > + > > + while (success =3D=3D 0) { > > + x =3D rwl->cnt; > > + /* write lock is held */ > > + if (x < 0) > > + return -EBUSY; > > + success =3D rte_atomic32_cmpset((volatile uint32_t *)&rwl->cnt, > > + (uint32_t)x, (uint32_t)(x + 1)); > > + } > > + return 0; > > +} > > + > > /** > > * Release a read lock. > > * > > @@ -87,6 +114,33 @@ rte_rwlock_read_unlock(rte_rwlock_t *rwl) > > rte_atomic32_dec((rte_atomic32_t *)(intptr_t)&rwl->cnt); } > > > > +/** > Please add the experimental API warning >=20 > > + * try to take a write lock. > > + * > > + * @param rwl > > + * A pointer to a rwlock structure. > > + * @return > > + * - zero if the lock is successfully taken > > + * - -EBUSY if lock could not be acquired for writing because > > + * it was already locked for reading or writing > > + */ > > +static inline __rte_experimental int > > +rte_rwlock_write_trylock(rte_rwlock_t *rwl) { > > + int32_t x; > > + int success =3D 0; > > + > > + while (success =3D=3D 0) { (Apologies for not thinking through all my comments earlier) I am wondering if the 'while' loop is required for the write lock. > > + x =3D rwl->cnt; > > + /* a lock is held */ > > + if (x !=3D 0) > > + return -EBUSY; > > + success =3D rte_atomic32_cmpset((volatile uint32_t *)&rwl->cnt, > > + 0, (uint32_t)-1); This might fail as the lock was taken (either reader or writer). We should = return from here as it already indicates that the lock is not available for= the writer to take. Otherwise, there is a possibility that the while loop = will run for multiple iterations. I would think, from the user's expectatio= n, it might not be correct. In the read_trylock, the while loop should be fine because the write lock i= tself is not held. The failure could be because some other reader increment= ed the counter before we did. i.e. the reader lock itself may be available = to take in the next iteration. > > + } > > + return 0; > > +} > > + > > /** > > * Take a write lock. Loop until the lock is held. > > * > > diff --git a/lib/librte_eal/rte_eal_version.map > > b/lib/librte_eal/rte_eal_version.map > > index 3fe78260d..8b1593dd8 100644 > > --- a/lib/librte_eal/rte_eal_version.map > > +++ b/lib/librte_eal/rte_eal_version.map > > @@ -355,6 +355,8 @@ EXPERIMENTAL { > > rte_mp_request_async; > > rte_mp_sendmsg; > > rte_option_register; > > + rte_rwlock_read_trylock; > > + rte_rwlock_write_trylock; > I do not see the other RW lock APIs in this file. >=20 > > rte_service_lcore_attr_get; > > rte_service_lcore_attr_reset_all; > > rte_service_may_be_active; > > -- > > 2.17.1 >=20 > Other than the minor comments, > Reviewed-by: Honnappa Nagarahalli