Hi Honnappa, > -----Original Message----- > From: dev <dev-boun...@dpdk.org> On Behalf Of Honnappa Nagarahalli > Sent: Tuesday, April 23, 2019 12:32 > To: konstantin.anan...@intel.com; step...@networkplumber.org; > paul...@linux.ibm.com; marko.kovace...@intel.com; dev@dpdk.org > Cc: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; Gavin Hu (Arm > Technology China) <gavin...@arm.com>; Dharmik Thakkar > <dharmik.thak...@arm.com>; Malvika Gupta <malvika.gu...@arm.com> > Subject: [dpdk-dev] [PATCH v7 3/3] doc/rcu: add lib_rcu documentation >
*snip* > +Let us consider the following diagram: > + > +.. figure:: img/rcu_general_info.* > + > + > +As shown, reader thread 1 accesses data structures D1 and D2. When it > +is accessing D1, if the writer has to remove an element from D1, the > +writer cannot free the memory associated with that element immediately. > +The writer can return the memory to the allocator only after the reader > +stops referencing D1. In other words, reader thread RT1 has to enter a > +quiescent state. > + > +Similarly, since reader thread 2 is also accessing D1, writer has to > +wait till thread 2 enters quiescent state as well. > + > +However, the writer does not need to wait for reader thread 3 to enter > +quiescent state. Reader thread 3 was not accessing D1 when the delete > +operation happened. So, reader thread 1 will not have a reference to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ thread 3 ? > +the deleted entry. > + *snip*
