lttng-dev Archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: linux-kernel@vger.kernel.org, lttng-dev@lists.lttng.org,
	rp@svcs.cs.pdx.edu
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Lai Jiangshan <jiangshanlai@gmail.com>
Subject: [lttng-dev] [RELEASE] Userspace RCU 0.14.0, 0.13.3, 0.12.5 [EOL]
Date: Tue, 14 Feb 2023 11:45:28 -0500	[thread overview]
Message-ID: <52cf1b10-3dd0-fc20-3cb5-9cbf1f4b72bd@efficios.com> (raw)

Hi,

This is a release announcement for the Userspace RCU project.

This is a set of releases, including the new 0.14 branch with the 0.14.0 
release, and bug fix releases for the 0.13 and 0.12 branches. The 0.12.5 
release is the last of the 0.12 branch, which reaches end of life with 
the release of 0.14.

Here are the new features introduced in urcu 0.14.0:

- C99 and C++11 are now the baseline requirements, as documented in
   README.md.

- Introduce public APIs for C++,

   An important point to consider: urcu/compiler.h needs to include
   <type_traits> in C++, which prevents including urcu/compiler.h
   from extern "C" code.

- Introduce new grace period polling APIs in urcu-memb,mb,signal,qsbr,bp
   flavors:

   struct urcu_gp_poll_state start_poll_synchronize_rcu(void);
   bool poll_state_synchronize_rcu(struct urcu_gp_poll_state state);

   This allow periodically polling to check if a started grace period has
   completed, and thus check for grace period completion and some other
   condition as well.

- rculfhash: introduce cds_lfht_node_init_deleted

   Allow initializing lfht node to "removed" state to allow querying
   whether the node is published in a hash table before it is added to
   the hash table and after it has been removed from the hash table.

- Disable signals in URCU background threads

   Applications using signalfd depend on signals being blocked in all
   threads of the process, otherwise threads with unblocked signals
   can receive them and starve the signalfd.

   While some threads in URCU do block signals (e.g. workqueue
   worker for rculfhash), the call_rcu, defer_rcu, and rculfhash
   partition_resize_helper threads do not.

   Always block all signals before creating threads, and only unblock
   SIGRCU when registering a urcu-signal thread. Restore the SIGRCU
   signal to its pre-registration blocked state on unregistration.

   For rculfhash, cds_lfht_worker_init can be removed, because its only
   effect is to block all signals except SIGRCU. Blocking all signals is
   already done by the workqueue code, and unbloking SIGRCU is now done
   by the urcu signal flavor thread regisration.

- Always use '__thread' for Thread local storage except on MSVC

   Use the GCC extension '__thread' [1] for Thread local storage on all C
   and C++ compilers except MSVC.

   While C11 and C++11 respectively offer '_Thread_local' and
   'thread_local' as potentialy faster implementations, they offer no
   guarantees of compatibility when used in a library interface which
   might be used by both C and C++ client code.

- Various test framework improvements.

- Wire up membarrier system call on Alpha. The only missing architecture
   without membarrier wired up is MIPS. https://bugs.lttng.org/issues/940


Here are the fixes introduced in urcu 0.14.0, 0.13.3 and 0.12.5:

- Fix: auto-resize hash table destroy deadlock

   Fix a deadlock for auto-resize hash tables when cds_lfht_destroy
   is called with RCU read-side lock held.

- Join call_rcu worker thread in call_rcu_data_free (eliminate leaks)

- Teardown default call_rcu worker on application exit

   Teardown the default call_rcu worker thread if there are no queued
   callbacks on process exit. This prevents leaking memory.

   Here is how an application can ensure graceful teardown of this
   worker thread:

   - An application queuing call_rcu callbacks should invoke
     rcu_barrier() before it exits.
   - When chaining call_rcu callbacks, the number of calls to
     rcu_barrier() on application exit must match at least the maximum
     number of chained callbacks.
   - If an application chains callbacks endlessly, it would have to be
     modified to stop chaining callbacks when it detects an application
     exit (e.g. with a flag), and wait for quiescence with rcu_barrier()
     after setting that flag.
   - The statements above apply to a library which queues call_rcu
     callbacks, only it needs to invoke rcu_barrier in its library
     destructor.

- Allow building on MSYS2

   Update cygwin libtool config in `configure.ac` to match MSYS2 build
   environments as well. MSYS2 is also a Windows build environment that
   produces DLLs.

Feedback is welcome!

Mathieu


Project website: https://liburcu.org
Git repository: git://git.liburcu.org/urcu.git

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

                 reply	other threads:[~2023-02-14 16:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52cf1b10-3dd0-fc20-3cb5-9cbf1f4b72bd@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rp@svcs.cs.pdx.edu \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).