1 unstable release
0.1.0 | Mar 16, 2021 |
---|
#786 in Embedded development
8,511 downloads per month
19KB
185 lines
volatile-mem
A rust library for managing volatile memory.
lib.rs
:
This crate provides a type, Volatile
, for managing volatile memory or
data.
The Volatile
object does not contain a pointer or reference to the
volatile memory, but is a container of the volatile data itself. This means
that a pointer to a Volatile
object is a pointer to the volatile memory.
As such, it would make little or no sense to create a local variable or
parameter of type Volatile
. You would typically use some kind of pointer
or reference to the Volatile
object instead.
Besides Volatile
, the crate provides two additional volatile types. They
are VolatileReadOnly
, and VolatileWriteOnly
. These are technically
just type definitions which alias read-only and write-only variants of
Volatile
, respectively. However, those variants are only available
through these aliases. The default variant for Volatile
allows both
reads and writes.
Volatile
is meant for reading from or writing to memory used for
communication with some process external to the program. A common use case
would be memory-mapped I/O.
Safety
Typically, Volatile
would be created from a raw pointer, which carries
with it the typical pointer safety concerns. In
particular, the following must be guaranteed regarding the location of the
volatile memory.
-
The memory must be valid for reads and/or writes.
-
The memory must be properly aligned.
-
The memory must point to a properly initialized for the data type, unless the
Volatile
is write-only.
Note that even if the data has size zero, the pointer must be non-NULL and properly aligned.
Do not forget that even creating a reference to uninitialized data (even if
that data is never used) is immediate undefined behavior. As such, do not at
any point create a reference directly to uninitialized data (as opposed to a
reference to VolatileWriteOnly
or MaybeUninit
,
each of which can safely handle uninitialized data).
Just like in C, whether an operation is volatile has no bearing whatsoever on questions involving concurrent access from multiple threads. Volatile accesses behave exactly like non-atomic accesses in that regard. In particular, a race between a write operation and any other operation (reading or writing) to the same location is undefined behavior.
Disclaimer
The Rust documentation contains the following note regarding volatile reads and writes:
Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time. That being said, the semantics will almost always end up pretty similar to C11's definition of volatile.
The compiler shouldn't change the relative order or number of volatile memory operations. However, volatile memory operations on zero-sized types [...] are noops and may be ignored.