25 releases

0.3.10 Oct 13, 2024
0.3.9 Oct 13, 2024
0.3.2 Aug 19, 2024
0.3.0 Jul 26, 2024
0.1.11 Jun 30, 2024

#96 in Concurrency

Download history 269/week @ 2024-07-27 16/week @ 2024-08-03 144/week @ 2024-08-10 292/week @ 2024-08-17 99/week @ 2024-08-24 42/week @ 2024-08-31 14/week @ 2024-09-07 142/week @ 2024-09-14 73/week @ 2024-09-21 135/week @ 2024-09-28 23/week @ 2024-10-05 1144/week @ 2024-10-12 68/week @ 2024-10-19 11/week @ 2024-10-26 16/week @ 2024-11-02 11/week @ 2024-11-09

157 downloads per month
Used in 13 crates (9 directly)

Apache-2.0

140KB
4K SLoC

RTSC - Real-time Synchronization Components crates.io page docs.rs page

Requirements for data synchronization in real-time applications differ from traditional high-load ones. The main difference is that real-time synchronization components must carefully respect and follow the traditional operating-system approach, avoid user-space spin-loops and other busy-waiting techniques (see Channels in Rust. Part 2 where such problems are clearly described).

Components

This crate provides a pack of real-time-safe synchronization components for various typical and custom use-cases.

  • Data Buffer
  • Synchronization cells
  • Sync/async channels
  • Policy-based channels
  • Semaphore
  • Time tools

Locking policy

All the components support both the default and custom locking policies, mean Mutex and Condvar implementations can be replaced with 3rd party ones for each component instance used.

This allows to use RTSC components in various environments, e.g.:

  • For standard real-time: use parking_lot_rt (default for all systems except Linux).

  • For safety-critical real-time use the provided [pi] components which support priority inheritance (default for Linux, works on Linux only, recommended Kernel 5.14+).

  • For latency-critical real-time use spin-based locks.

  • For high-load non-real-time use parking_lot components.

The default locking policy

// For the implicit <T>
let (tx, rx) = rtsc::channel_bounded!(10);
tx.send(42).unwrap();

// For the explicit <T>
use rtsc::channel;

// The `Bounded` structure is used as a workaround to specify the default
// Mutex/Condvar, being destructuring to the sender and the receiver.
let channel::Bounded { tx, rx } = channel::Bounded::<i32>::new(10);

On Linux the crate uses built-in priority-inheritance pi::Mutex implementation and re-exports this module as locking.

On other platforms, all components use Mutex/Condvar synchronization primitives from parking_lot_rt - a real-time fork of the well-known parking_lot crate. This is a relatively safe Mutex/RwLock with minimal user-space spin-waiting. The module is re-exported as locking as well.

Custom locking policy

The crate components provide API to specify 3rd party Mutex/Condvar implementation.

// Forcibly use the parking_lot_rt Mutex/Condvar
let (tx, rx) = rtsc::channel::bounded::<i32,
    parking_lot_rt::RawMutex, parking_lot_rt::Condvar>(1);

Note: asynchronous channels use parking_lot_rt locking only.

Supported mutexes

All mutexes, which implement locking_api::RawMutex trait from the lock_api crate.

Supported condition variables

For the condition variables, the trait condvar_api::RawCondvar must be implemented.

The trait is automatically implemented for:

  • The Built-in locks provided

  • parking_lot::Condvar (requires parking_lot feature)

References

RTSC is a part of RoboPLC project.

Dependencies

~3.5–8.5MB
~93K SLoC