| 1 | Userspace RCU Implementation |
| 2 | ============================ |
| 3 | |
| 4 | by Mathieu Desnoyers and Paul E. McKenney |
| 5 | |
| 6 | |
| 7 | Building |
| 8 | -------- |
| 9 | |
| 10 | ./bootstrap # skip if using tarball |
| 11 | ./configure |
| 12 | make |
| 13 | make install |
| 14 | ldconfig |
| 15 | |
| 16 | Hints: |
| 17 | |
| 18 | - Forcing 32-bit build: |
| 19 | |
| 20 | CFLAGS="-m32 -g -O2" ./configure |
| 21 | |
| 22 | - Forcing 64-bit build: |
| 23 | |
| 24 | CFLAGS="-m64 -g -O2" ./configure |
| 25 | |
| 26 | - Forcing a 32-bit build with 386 backward compatibility: |
| 27 | |
| 28 | CFLAGS="-m32 -g -O2" ./configure --host=i386-pc-linux-gnu |
| 29 | |
| 30 | - Forcing a 32-bit build for Sparcv9 (typical for Sparc v9) |
| 31 | |
| 32 | CFLAGS="-m32 -Wa,-Av9a -g -O2" ./configure |
| 33 | |
| 34 | |
| 35 | Architectures supported |
| 36 | ----------------------- |
| 37 | |
| 38 | Currently, the following architectures are supported: |
| 39 | |
| 40 | - x86 (i386, i486, i586, i686) |
| 41 | - amd64 / x86_64 |
| 42 | - PowerPC 32/64 |
| 43 | - S390, S390x |
| 44 | - ARM 32/64 |
| 45 | - MIPS |
| 46 | - NIOS2 |
| 47 | - Alpha |
| 48 | - ia64 |
| 49 | - Sparcv9 32/64 |
| 50 | - Tilera |
| 51 | - hppa/PA-RISC |
| 52 | - m68k |
| 53 | - RISC-V |
| 54 | |
| 55 | Tested on: |
| 56 | |
| 57 | - Linux all architectures |
| 58 | - FreeBSD 8.2/8.3/9.0/9.1/10.0 i386/amd64 |
| 59 | - Solaris 10/11 i386 |
| 60 | - Cygwin i386/amd64 |
| 61 | - MacOS amd64/arm64 |
| 62 | |
| 63 | Should also work on: |
| 64 | |
| 65 | - Android |
| 66 | - NetBSD 5 |
| 67 | - OpenBSD |
| 68 | - Darwin |
| 69 | |
| 70 | (more testing needed before claiming support for these OS). |
| 71 | |
| 72 | Linux ARM depends on running a Linux kernel 2.6.15 or better, GCC 4.4 or |
| 73 | better. |
| 74 | |
| 75 | The C compiler used needs to support at least C99. The C++ compiler used |
| 76 | needs to support at least C++11. |
| 77 | |
| 78 | The GCC compiler versions 3.3, 3.4, 4.0, 4.1, 4.2, 4.3, 4.4 and 4.5 are |
| 79 | supported, with the following exceptions: |
| 80 | |
| 81 | - GCC 3.3 and 3.4 have a bug that prevents them from generating volatile |
| 82 | accesses to offsets in a TLS structure on 32-bit x86. These versions are |
| 83 | therefore not compatible with `liburcu` on x86 32-bit |
| 84 | (i386, i486, i586, i686). |
| 85 | The problem has been reported to the GCC community: |
| 86 | http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg281255.html |
| 87 | - GCC 3.3 cannot match the "xchg" instruction on 32-bit x86 build. |
| 88 | See http://kerneltrap.org/node/7507 |
| 89 | - Alpha, ia64 and ARM architectures depend on GCC 4.x with atomic builtins |
| 90 | support. For ARM this was introduced with GCC 4.4: |
| 91 | http://gcc.gnu.org/gcc-4.4/changes.html. |
| 92 | - Linux aarch64 depends on GCC 5.1 or better because prior versions |
| 93 | perform unsafe access to deallocated stack. |
| 94 | |
| 95 | Clang version 3.0 (based on LLVM 3.0) is supported. |
| 96 | |
| 97 | Glibc >= 2.4 should work but the older version we test against is |
| 98 | currently 2.17. |
| 99 | |
| 100 | For developers using the Git tree: |
| 101 | |
| 102 | This source tree is based on the autotools suite from GNU to simplify |
| 103 | portability. Here are some things you should have on your system in order to |
| 104 | compile the git repository tree : |
| 105 | |
| 106 | - GNU autotools (automake >=1.12, autoconf >=2.69) |
| 107 | (make sure your system wide `automake` points to a recent version!) |
| 108 | - GNU Libtool >=2.2 |
| 109 | (for more information, go to http://www.gnu.org/software/autoconf/) |
| 110 | |
| 111 | If you get the tree from the repository, you will need to use the `bootstrap` |
| 112 | script in the root of the tree. It calls all the GNU tools needed to prepare |
| 113 | the tree configuration. |
| 114 | |
| 115 | Test scripts provided in the `tests/` directory of the source tree depend |
| 116 | on `bash` and the `seq` program. |
| 117 | |
| 118 | |
| 119 | API |
| 120 | --- |
| 121 | |
| 122 | See the relevant API documentation files in `doc/`. The APIs provided by |
| 123 | Userspace RCU are, by prefix: |
| 124 | |
| 125 | - `rcu_`: Read-Copy Update (see [`doc/rcu-api.md`](doc/rcu-api.md)) |
| 126 | - `cmm_`: Concurrent Memory Model |
| 127 | - `caa_`: Concurrent Architecture Abstraction |
| 128 | - `cds_`: Concurrent Data Structures |
| 129 | (see [`doc/cds-api.md`](doc/cds-api.md)) |
| 130 | - `uatomic_`: Userspace Atomic |
| 131 | (see [`doc/uatomic-api.md`](doc/uatomic-api.md)) |
| 132 | |
| 133 | |
| 134 | Quick start guide |
| 135 | ----------------- |
| 136 | |
| 137 | ### Usage of all urcu libraries: |
| 138 | |
| 139 | - Define `_LGPL_SOURCE` (only) if your code is LGPL or GPL compatible |
| 140 | before including the `urcu.h` or `urcu-qsbr.h` header. If your application |
| 141 | is distributed under another license, function calls will be generated |
| 142 | instead of inlines, so your application can link with the library. |
| 143 | - Linking with one of the libraries below is always necessary even for |
| 144 | LGPL and GPL applications. |
| 145 | - Define `URCU_INLINE_SMALL_FUNCTIONS` before including Userspace RCU |
| 146 | headers if you want Userspace RCU to inline small functions (10 |
| 147 | lines or less) into the application. It can be used by applications |
| 148 | distributed under any kind of license, and does *not* make the |
| 149 | application a derived work of Userspace RCU. |
| 150 | |
| 151 | Those small inlined functions are guaranteed to match the library |
| 152 | content as long as the library major version is unchanged. |
| 153 | Therefore, the application *must* be compiled with headers matching |
| 154 | the library major version number. Applications using |
| 155 | `URCU_INLINE_SMALL_FUNCTIONS` may be unable to use debugging |
| 156 | features of Userspace RCU without being recompiled. |
| 157 | |
| 158 | There are multiple flavors of liburcu available: |
| 159 | |
| 160 | - `memb`, |
| 161 | - `qsbr`, |
| 162 | - `mb`, |
| 163 | - `signal`, |
| 164 | - `bp`. |
| 165 | |
| 166 | The API members start with the prefix "urcu_<flavor>_", where |
| 167 | <flavor> is the chosen flavor name. |
| 168 | |
| 169 | |
| 170 | ### Usage of `liburcu-memb` |
| 171 | |
| 172 | 1. `#include <urcu/urcu-memb.h>` |
| 173 | 2. Link the application with `-lurcu-memb` |
| 174 | |
| 175 | This is the preferred version of the library, in terms of |
| 176 | grace-period detection speed, read-side speed and flexibility. |
| 177 | Dynamically detects kernel support for `sys_membarrier()`. Falls back |
| 178 | on `urcu-mb` scheme if support is not present, which has slower |
| 179 | read-side. Use the --disable-sys-membarrier-fallback configure option |
| 180 | to disable the fall back, thus requiring `sys_membarrier()` to be |
| 181 | available. This gives a small speedup when `sys_membarrier()` is |
| 182 | supported by the kernel, and aborts in the library constructor if not |
| 183 | supported. |
| 184 | |
| 185 | |
| 186 | ### Usage of `liburcu-qsbr` |
| 187 | |
| 188 | 1. `#include <urcu/urcu-qsbr.h>` |
| 189 | 2. Link with `-lurcu-qsbr` |
| 190 | |
| 191 | The QSBR flavor of RCU needs to have each reader thread executing |
| 192 | `rcu_quiescent_state()` periodically to progress. `rcu_thread_online()` |
| 193 | and `rcu_thread_offline()` can be used to mark long periods for which |
| 194 | the threads are not active. It provides the fastest read-side at the |
| 195 | expense of more intrusiveness in the application code. |
| 196 | |
| 197 | |
| 198 | ### Usage of `liburcu-mb` |
| 199 | |
| 200 | 1. `#include <urcu/urcu-mb.h>` |
| 201 | 2. Link with `-lurcu-mb` |
| 202 | |
| 203 | This version of the urcu library uses memory barriers on the writer |
| 204 | and reader sides. This results in faster grace-period detection, but |
| 205 | results in slower reads. |
| 206 | |
| 207 | |
| 208 | ### Usage of `liburcu-signal` |
| 209 | |
| 210 | 1. `#include <urcu/urcu-signal.h>` |
| 211 | 2. Link the application with `-lurcu-signal` |
| 212 | |
| 213 | Version of the library that requires a signal, typically `SIGUSR1`. Can |
| 214 | be overridden with `-DSIGRCU` by modifying `Makefile.build.inc`. |
| 215 | |
| 216 | |
| 217 | ### Usage of `liburcu-bp` |
| 218 | |
| 219 | 1. `#include <urcu/urcu-bp.h>` |
| 220 | 2. Link with `-lurcu-bp` |
| 221 | |
| 222 | The BP library flavor stands for "bulletproof". It is specifically |
| 223 | designed to help tracing library to hook on applications without |
| 224 | requiring to modify these applications. `urcu_bp_init()`, and |
| 225 | `urcu_bp_unregister_thread()` all become nops, whereas calling |
| 226 | `urcu_bp_register_thread()` becomes optional. The state is dealt with by |
| 227 | the library internally at the expense of read-side and write-side |
| 228 | performance. |
| 229 | |
| 230 | |
| 231 | ### Initialization |
| 232 | |
| 233 | Each thread that has reader critical sections (that uses |
| 234 | `urcu_<flavor>_read_lock()`/`urcu_<flavor>_read_unlock()` must first |
| 235 | register to the URCU library. This is done by calling |
| 236 | `urcu_<flavor>_register_thread()`. Unregistration must be performed |
| 237 | before exiting the thread by using `urcu_<flavor>_unregister_thread()`. |
| 238 | |
| 239 | |
| 240 | ### Reading |
| 241 | |
| 242 | Reader critical sections must be protected by locating them between |
| 243 | calls to `urcu_<flavor>_read_lock()` and `urcu_<flavor>_read_unlock()`. |
| 244 | Inside that lock, `rcu_dereference()` may be called to read an RCU |
| 245 | protected pointer. |
| 246 | |
| 247 | |
| 248 | ### Writing |
| 249 | |
| 250 | `rcu_assign_pointer()` and `rcu_xchg_pointer()` may be called anywhere. |
| 251 | After, `urcu_<flavor>_synchronize_rcu()` must be called. When it |
| 252 | returns, the old values are not in usage anymore. |
| 253 | |
| 254 | |
| 255 | ### Usage of `liburcu-defer` |
| 256 | |
| 257 | - Follow instructions for either `liburcu-memb`, `liburcu-qsbr`, |
| 258 | `liburcu-mb`, `liburcu-signal`, or `liburcu-bp` above. |
| 259 | The `liburcu-defer` functionality is pulled into each of |
| 260 | those library modules. |
| 261 | - Provides `urcu_<flavor>_defer_rcu()` primitive to enqueue delayed |
| 262 | callbacks. Queued callbacks are executed in batch periodically after |
| 263 | a grace period. Do _not_ use `urcu_<flavor>_defer_rcu()` within a |
| 264 | read-side critical section, because it may call |
| 265 | `urcu_<flavor>_synchronize_rcu()` if the thread queue is full. This |
| 266 | can lead to deadlock or worse. |
| 267 | - Requires that `urcu_<flavor>_defer_barrier()` must be called in |
| 268 | library destructor if a library queues callbacks and is expected to |
| 269 | be unloaded with `dlclose()`. |
| 270 | |
| 271 | Its API is currently experimental. It may change in future library releases. |
| 272 | |
| 273 | |
| 274 | ### Usage of `urcu-call-rcu` |
| 275 | |
| 276 | - Follow instructions for either `liburcu-memb`, `liburcu-qsbr`, |
| 277 | `liburcu-mb`, `liburcu-signal`, or `liburcu-bp` above. |
| 278 | The `urcu-call-rcu` functionality is pulled into each of |
| 279 | those library modules. |
| 280 | - Provides the `urcu_<flavor>_call_rcu()` primitive to enqueue delayed |
| 281 | callbacks in a manner similar to `urcu_<flavor>_defer_rcu()`, but |
| 282 | without ever delaying for a grace period. On the other hand, |
| 283 | `urcu_<flavor>_call_rcu()`'s best-case overhead is not quite as good |
| 284 | as that of `urcu_<flavor>_defer_rcu()`. |
| 285 | - Provides `urcu_<flavor>_call_rcu()` to allow asynchronous handling |
| 286 | of RCU grace periods. A number of additional functions are provided |
| 287 | to manage the helper threads used by `urcu_<flavor>_call_rcu()`, but |
| 288 | reasonable defaults are used if these additional functions are not |
| 289 | invoked. See [`doc/rcu-api.md`](doc/rcu-api.md) in userspace-rcu |
| 290 | documentation for more details. |
| 291 | |
| 292 | |
| 293 | ### Being careful with signals |
| 294 | |
| 295 | The `liburcu-signal` library uses signals internally. The signal handler is |
| 296 | registered with the `SA_RESTART` flag. However, these signals may cause |
| 297 | some non-restartable system calls to fail with `errno = EINTR`. Care |
| 298 | should be taken to restart system calls manually if they fail with this |
| 299 | error. A list of non-restartable system calls may be found in |
| 300 | `signal(7)`. |
| 301 | |
| 302 | Read-side critical sections are allowed in a signal handler, |
| 303 | except those setup with `sigaltstack(2)`, with `liburcu-memb` and |
| 304 | `liburcu-mb`. Be careful, however, to disable these signals |
| 305 | between thread creation and calls to `urcu_<flavor>_register_thread()`, |
| 306 | because a signal handler nesting on an unregistered thread would not be |
| 307 | allowed to call `urcu_<flavor>_read_lock()`. |
| 308 | |
| 309 | Read-side critical sections are _not_ allowed in a signal handler with |
| 310 | `liburcu-qsbr`, unless signals are disabled explicitly around each |
| 311 | `urcu_qsbr_quiescent_state()` calls, when threads are put offline and around |
| 312 | calls to `urcu_qsbr_synchronize_rcu()`. Even then, we do not recommend it. |
| 313 | |
| 314 | |
| 315 | ### Interaction with mutexes |
| 316 | |
| 317 | One must be careful to do not cause deadlocks due to interaction of |
| 318 | `urcu_<flavor>_synchronize_rcu()` and RCU read-side with mutexes. If |
| 319 | `urcu_<flavor>_synchronize_rcu()` is called with a mutex held, this |
| 320 | mutex (or any mutex which has this mutex in its dependency chain) should |
| 321 | not be acquired from within a RCU read-side critical section. |
| 322 | |
| 323 | This is especially important to understand in the context of the |
| 324 | QSBR flavor: a registered reader thread being "online" by |
| 325 | default should be considered as within a RCU read-side critical |
| 326 | section unless explicitly put "offline". Therefore, if |
| 327 | `urcu_qsbr_synchronize_rcu()` is called with a mutex held, this mutex, |
| 328 | as well as any mutex which has this mutex in its dependency chain should |
| 329 | only be taken when the RCU reader thread is "offline" (this can be |
| 330 | performed by calling `urcu_qsbr_thread_offline()`). |
| 331 | |
| 332 | |
| 333 | ### Interaction with `fork()` |
| 334 | |
| 335 | Special care must be taken for applications performing `fork()` without |
| 336 | any following `exec()`. This is caused by the fact that Linux only clones |
| 337 | the thread calling `fork()`, and thus never replicates any of the other |
| 338 | parent thread into the child process. Most `liburcu` implementations |
| 339 | require that all registrations (as reader, `defer_rcu` and `call_rcu` |
| 340 | threads) should be released before a `fork()` is performed, except for the |
| 341 | rather common scenario where `fork()` is immediately followed by `exec()` in |
| 342 | the child process. The only implementation not subject to that rule is |
| 343 | `liburcu-bp`, which is designed to handle `fork()` by calling |
| 344 | `urcu_bp_before_fork`, `urcu_bp_after_fork_parent` and |
| 345 | `urcu_bp_after_fork_child`. |
| 346 | |
| 347 | Applications that use `urcu_<flavor>_call_rcu()` and that `fork()` |
| 348 | without doing an immediate `exec()` must take special action. The |
| 349 | parent must invoke `urcu_<flavor>_call_rcu_before_fork()` before the |
| 350 | `fork()` and `urcu_<flavor>_call_rcu_after_fork_parent()` after the |
| 351 | `fork()`. The child process must invoke |
| 352 | `urcu_<flavor>_call_rcu_after_fork_child()`. Even though these three |
| 353 | APIs are suitable for passing to `pthread_atfork()`, use of |
| 354 | `pthread_atfork()` is **STRONGLY DISCOURAGED** for programs calling the |
| 355 | glibc memory allocator (`malloc()`, `calloc()`, `free()`, ...) within |
| 356 | `urcu_<flavor>_call_rcu` callbacks. This is due to limitations in the |
| 357 | way glibc memory allocator handles calls to the memory allocator from |
| 358 | concurrent threads while the `pthread_atfork()` handlers are executing. |
| 359 | |
| 360 | Combining e.g.: |
| 361 | |
| 362 | - call to `free()` from callbacks executed within |
| 363 | `urcu_<flavor>_call_rcu` worker threads, |
| 364 | - executing `urcu_<flavor>_call_rcu` atfork handlers within the glibc |
| 365 | pthread atfork mechanism, |
| 366 | |
| 367 | will sometimes trigger interesting process hangs. This usually |
| 368 | hangs on a memory allocator lock within glibc. |
| 369 | |
| 370 | |
| 371 | ### Thread Local Storage (TLS) |
| 372 | |
| 373 | Userspace RCU can fall back on `pthread_getspecific()` to emulate |
| 374 | TLS variables on systems where it is not available. This behavior |
| 375 | can be forced by specifying `--disable-compiler-tls` as configure |
| 376 | argument. |
| 377 | |
| 378 | |
| 379 | ### Usage of `DEBUG_RCU` & `--enable-rcu-debug` |
| 380 | |
| 381 | By default the library is configured with internal debugging |
| 382 | self-checks disabled. |
| 383 | |
| 384 | For always-on debugging self-checks: |
| 385 | ./configure --enable-rcu-debug |
| 386 | |
| 387 | For fine grained enabling of debugging self-checks, build |
| 388 | userspace-rcu with DEBUG_RCU defined and compile dependent |
| 389 | applications with DEBUG_RCU defined when necessary. |
| 390 | |
| 391 | Warning: Enabling this feature result in a performance penalty. |
| 392 | |
| 393 | |
| 394 | ### Usage of `DEBUG_YIELD` |
| 395 | |
| 396 | `DEBUG_YIELD` is used to add random delays in the code for testing |
| 397 | purposes. |
| 398 | |
| 399 | |
| 400 | ### SMP support |
| 401 | |
| 402 | By default the library is configured to use synchronization primitives |
| 403 | adequate for SMP systems. On uniprocessor systems, support for SMP |
| 404 | systems can be disabled with: |
| 405 | |
| 406 | ./configure --disable-smp-support |
| 407 | |
| 408 | theoretically yielding slightly better performance. |
| 409 | |
| 410 | |
| 411 | ### Usage of `--enable-cds-lfht-iter-debug` |
| 412 | |
| 413 | By default the library is configured with extra debugging checks for |
| 414 | lock-free hash table iterator traversal disabled. |
| 415 | |
| 416 | Building liburcu with --enable-cds-lfht-iter-debug and rebuilding |
| 417 | application to match the ABI change allows finding cases where the hash |
| 418 | table iterator is re-purposed to be used on a different hash table while |
| 419 | still being used to iterate on a hash table. |
| 420 | |
| 421 | This option alters the rculfhash ABI. Make sure to compile both library |
| 422 | and application with matching configuration. |
| 423 | |
| 424 | |
| 425 | Make targets |
| 426 | ------------ |
| 427 | |
| 428 | In addition to the usual `make check` target, Userspace RCU features |
| 429 | `make regtest`, `make short_bench` and `make long_bench` targets: |
| 430 | |
| 431 | - `make check`: short tests, meant to be run when rebuilding or |
| 432 | porting Userspace RCU. |
| 433 | - `make regtest`: long (many hours) test, meant to be run when |
| 434 | modifying Userspace RCU or porting it to a new architecture or |
| 435 | operating system. |
| 436 | - `make short_bench`: short benchmarks, 3 seconds per test. |
| 437 | - `make long_bench`: long (many hours) benchmarks, 30 seconds per test. |
| 438 | |
| 439 | |
| 440 | Known issues |
| 441 | ------------ |
| 442 | |
| 443 | There is an application vs library compatibility issue between |
| 444 | applications built using Userspace RCU 0.10 headers linked against |
| 445 | Userspace RCU 0.11 or 0.12 shared objects. The problem occurs as |
| 446 | follows: |
| 447 | |
| 448 | - An application executable is built with _LGPL_SOURCE defined, includes |
| 449 | any of the Userspace RCU 0.10 urcu flavor headers, and is built |
| 450 | without the -fpic compiler option. |
| 451 | |
| 452 | - The Userspace RCU 0.10 library shared objects are updated to 0.11 |
| 453 | or 0.12 without rebuilding the application. |
| 454 | |
| 455 | - The application will hang, typically when RCU grace period |
| 456 | (synchronize_rcu) is invoked. |
| 457 | |
| 458 | Some possible work-arounds for this are: |
| 459 | |
| 460 | - Rebuild the application against Userspace RCU 0.11+. |
| 461 | |
| 462 | - Rebuild the application with -fpic. |
| 463 | |
| 464 | - Upgrade Userspace RCU to 0.13+ without installing 0.11 nor 0.12. |
| 465 | |
| 466 | |
| 467 | Contacts |
| 468 | -------- |
| 469 | |
| 470 | You can contact the maintainers on the following mailing list: |
| 471 | `lttng-dev@lists.lttng.org`. |