Replace explicit rcu_read_lock/unlock with lttng::urcu::read_lock_guard
authorJérémie Galarneau <jeremie.galarneau@efficios.com>
Sat, 28 Jan 2023 09:54:09 +0000 (04:54 -0500)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 2 Feb 2023 22:06:41 +0000 (17:06 -0500)
The explicit use of rcu_read_lock/unlock() has been a frequent source of
bugs in the code base as the locks can often end-up imbalanced when
error paths are taken (through goto's).

Since lttng::urcu::read_lock_guard was implemented in a previous commit,
replace all usages of the rcu_read_lock/unlock() API with an RAII
lock_guard wrapper.

Essentially, lttng::urcu::read_lock_guard acquires the RCU reader lock
on construction, and releases it when it goes out of scope. This
automates what is accomplished in the various error paths by jumping to
error handling labels.

For more info, see: https://en.cppreference.com/w/cpp/thread/lock_guard

No user-visible change of behaviour is intended by this patch. The scope
of some critical sections has been reduced when possible and when it
didn't matter from a correctness standpoint. The RCU reader lock would
often be held longer than necessary to simplify the error paths.

Explicit scopes are used to limit the lifetime of the reader lock guards
when used in long functions or when it is only intended to protect the
iteration over cds_lfht instances. In those cases, the following pattern
is used:

```cpp
void foo()
{
  [...]
  {
    lttng::urcu::read_lock_guard read_guard;

    cds_lfht_for_each(...) {
      [...]
  }
  [...]
}
```

This explicitly bounds the critical section and also serves as a hint as
to why the read guard is being used. It is fairly verbose, but I think
it's a good compromise until we add an idiomatic urcu wrapper that
automates this stuff too.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie3ef8ddf0f1ab813971522176115688939696370


No differences found
This page took 0.025212 seconds and 4 git commands to generate.