From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
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 <bruce.richardson@intel.com>
To: Ola Liljedahl <Ola.Liljedahl@arm.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
 "dev@dpdk.org" <dev@dpdk.org>,
 Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
 Steve Capper <Steve.Capper@arm.com>, nd <nd@arm.com>,
 "stable@dpdk.org" <stable@dpdk.org>
Message-ID: <20181008144349.GA21016@bricha3-MOBL.ger.corp.intel.com>
References: <AM6PR08MB3672E0CA10AAA9D587B9E13698EB0@AM6PR08MB3672.eurprd08.prod.outlook.com>
 <1555626C-F2B8-44EB-98A3-79B1F7002587@arm.com>
 <AM6PR08MB367225A0461ECC718D50CE9C98EB0@AM6PR08MB3672.eurprd08.prod.outlook.com>
 <60055965-A7C8-4E9F-8668-0AE1DCE57515@arm.com>
 <20181006074126.GA16715@jerin>
 <F83A969A-15F5-4D79-85B4-CB435E2C9B51@arm.com>
 <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-dev] [PATCH v3 1/3] ring: read tail using atomic load
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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:
<snip> 
> "* 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