[dpdk-dev] [PATCH v7 3/3] doc/rcu: add lib_rcu documentation
Ruifeng Wang (Arm Technology China)
Ruifeng.Wang at arm.com
Wed Apr 24 12:12:17 CEST 2019
Hi Honnappa,
> -----Original Message-----
> From: dev <dev-bounces at dpdk.org> On Behalf Of Honnappa Nagarahalli
> Sent: Tuesday, April 23, 2019 12:32
> To: konstantin.ananyev at intel.com; stephen at networkplumber.org;
> paulmck at linux.ibm.com; marko.kovacevic at intel.com; dev at dpdk.org
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>; Gavin Hu (Arm
> Technology China) <Gavin.Hu at arm.com>; Dharmik Thakkar
> <Dharmik.Thakkar at arm.com>; Malvika Gupta <Malvika.Gupta at 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*
More information about the dev
mailing list