|new 0.2.1||Jun 4, 2023|
|0.2.0||Jan 17, 2023|
|0.1.1||Feb 22, 2021|
|0.1.0||Feb 20, 2021|
#216 in Concurrency
This crate is experimental! Do not use in production.
It provides an inter thread communication channel called Signal.
Signal always has a single
Source and one or more
Sink's (single producer multiple consumer,
The behavior of signal differs from known channels such that there is no fifo like behavior.
Values are not taken out of the channel by a sink. They stay the same regardless how often they
will be read. The only way the Signal data can change is through the Source.
This decouples the frequency domains from the source and sinks.
In case a synchronous behavior of the Signal is required, where all sinks need to acknowledge the changed signal value, there is the signal::sync module. It provides the same interface as the default implementation and adds synchronization functionality. As it is assumed to be an exceptional requirement, it comes with a little more overhead.
This kind of behavior is probably useful in systems where a subsystem is processing data by sampling it's sources in a given frequency and the source signals may also run in different frequency's. Or if it is known that the source data is up to data at the time of sampling. The synced signal can be used to provide a trigger signal for multiple subsystems.
The underlying mechanism is inspired by page flipping, where one display buffer is displayed while the other can be modified. Hazard pointers are used to protect the atomic pointer which references the sink/read buffer.
Kudos to jonhoo. The Signal module was inspired by his streams and is powered by his hazard pointer implementation (jonhoo/haphazard).
Atomx is distributed under the terms of both the MIT license and the Apache License (Version 2.0). See LICENSE-APACHE and LICENSE-MIT for details.
Opening a pull request is assumed to signal agreement with these licensing terms.