From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 5C040D0B2; Mon, 8 Oct 2018 16:43:57 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2018 07:43:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,357,1534834800"; d="scan'208";a="97123320" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by fmsmga001.fm.intel.com with SMTP; 08 Oct 2018 07:43:53 -0700 Received: by (sSMTP sendmail emulation); Mon, 08 Oct 2018 15:43:50 +0100 Date: Mon, 8 Oct 2018 15:43:49 +0100 From: Bruce Richardson To: Ola Liljedahl Cc: Jerin Jacob , "dev@dpdk.org" , Honnappa Nagarahalli , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" , Steve Capper , nd , "stable@dpdk.org" Message-ID: <20181008144349.GA21016@bricha3-MOBL.ger.corp.intel.com> References: <1555626C-F2B8-44EB-98A3-79B1F7002587@arm.com> <60055965-A7C8-4E9F-8668-0AE1DCE57515@arm.com> <20181006074126.GA16715@jerin> <20181007040243.GA1850@jerin> <7A156041-23EC-4CCB-B129-3607AF34A992@arm.com> <20181008060629.GA5228@jerin> <063A95EC-CFC1-42F7-B864-DFB9C6718AC8@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063A95EC-CFC1-42F7-B864-DFB9C6718AC8@arm.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3 1/3] ring: read tail using atomic load X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:43:58 -0000 On Mon, Oct 08, 2018 at 09:22:05AM +0000, Ola Liljedahl wrote: > "* multi-producer safe lock-free ring buffer enqueue" > The comment is also wrong. This design is not lock-free, how could it be when there is spinning > (waiting) for other threads in the code? If a thread must wait for other threads, then by definition > the design is blocking. > My understanding is that the code is lock-free but not wait-free, though I'm not an expert in this area. /Bruce