From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wang, Yipeng1" Subject: Re: [PATCH v4 1/4] hash: fix race condition in iterate Date: Tue, 2 Oct 2018 23:53:36 +0000 Message-ID: References: <1537993618-92630-1-git-send-email-yipeng1.wang@intel.com> <1538155426-145177-1-git-send-email-yipeng1.wang@intel.com> <1538155426-145177-2-git-send-email-yipeng1.wang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "Gobriel, Sameh" , nd To: Honnappa Nagarahalli , "Richardson, Bruce" Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 7062D2C15 for ; Wed, 3 Oct 2018 01:57:31 +0200 (CEST) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >-----Original Message----- >From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] >> >> /* Get position of entry in key table */ >> >> position =3D h->buckets[bucket_idx].key_idx[idx]; >> >If we change the while loop as I suggested as above, we can remove this= line. >> > >> >> next_key =3D (struct rte_hash_key *) ((char *)h->key_store + >> >> [Wang, Yipeng] Sorry that I did not realize you already have it in your = patch >> set and I agree. >> Do you want to export it as a bug fix in your patch set? I will remove m= y >> change. >Sure, I will make a separate commit for this. [Wang, Yipeng] I fixed the issue you mentioned and put it in V5 and I saw y= ou acked it. You don't need to change you patch now. >> >> For the lock free, do we need to protect it with version counter? Imagin= e the >> following corner case: >> While the iterator read the key and data, there is a writer deleted, rem= oved, >> and recycled the key-data pair, and write a new key and data into it. Wh= ile the >> writer are writing, will the reader reads out wrong key/data, or mismatc= hed >> key/data? >> >In the lock-free algorithm, the key-data is not 'freed' until the readers = have completed all their references to the 'deleted' key-data. >Hence, the writers will not be able to allocate the same key store index t= ill the readers have stopped referring to the 'deleted' key- >data. >I re-checked my ladder diagrams [1] and I could not find any issues. > >[1] https://dpdkuserspace2018.sched.com/event/G44w/lock-free-read-write-co= ncurrency-in-rtehash (PPT) [Wang, Yipeng] After checking your slides, I agree. It works with upper level application = which should have RCU-like mechanisms to ensure the grace period has finished before recycling. In this case, the logic is = good!=20 If you haven't done so, could you be more specific in doc and the API comme= nt to indicate that the key-data pair recycle function should only be calle= d after reader finished (or maybe specifically indicate RCU type of mechanism= is needed?). I feel that users not familiar with this could easily get it wrong.=20 Besides this, I don't have other concern.