Re: [dpdk-dev] [PATCH v7 3/3] doc/rcu: add lib_rcu documentation

["Ruifeng Wang (Arm Technology China)" <Ruifeng.Wang@arm.com>]

Hi Honnappa,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Honnappa Nagarahalli
> Sent: Tuesday, April 23, 2019 12:32
> To: konstantin.ananyev@intel.com; stephen@networkplumber.org;
> paulmck@linux.ibm.com; marko.kovacevic@intel.com; dev@dpdk.org
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm
> Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@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*