Rust FFI and C Memory Model Integration: Shared Mutable State

Answer

Rust’s memory‑safety guarantees do not extend across the FFI boundary. If C code accesses Rust‑owned memory without proper synchronization, the behavior is undefined, even when the C program appears to work.

Confirmed facts

• Rust’s Sync and Send traits are enforced only for Rust code; the compiler assumes no concurrent access from foreign threads unless you provide it yourself.
• Violating Rust’s aliasing rules (e.g., allowing a mutable reference to coexist with an immutable reference or another mutable reference) results in undefined behavior, which the optimizer may exploit.
• The only way to obtain defined behavior when shared mutable state is accessed from C is to perform synchronization inside Rust (using Mutex, RwLock, or atomic types) and to expose only synchronized operations through extern "C" functions.

Steps for this case

1. Define the shared data with #[repr(C)] so its layout matches C expectations.
2. Wrap the data in a Rust synchronization primitive, e.g., std::sync::Mutex<T> or an atomic type.
3. Allocate the wrapped value on the heap (Box::new) and expose an opaque pointer (*mut T) to C via an extern "C" constructor that returns the pointer.
4. Provide extern "C" functions that lock the mutex (or perform the atomic operation), carry out the needed mutation or read, and then unlock. Never expose raw &mut or & references across the FFI.
5. Offer a destructor (extern "C" function) that drops the boxed value after all C threads have finished.
6. Initialize the mutex/atomic before any C thread calls the exposed functions, and destroy it after all C threads have joined.

Likely explanation if you observe undefined behavior

If a C thread mutates memory that Rust believes is exclusively owned or immutable, Rust’s optimizer may assume no concurrent modification and reorder or eliminate accesses. This leads to data races, torn reads/writes, or other undefined behavior that can manifest as crashes, silent corruption, or seemingly correct execution on some runs.

To confirm whether missing synchronization is the cause, check if the C side uses any locking or atomic primitives when accessing the shared state. If it does not, adding a Rust‑side lock (as described above) is required.

Missing diagnostic detail

Only if you cannot determine whether the C code already performs its own synchronization should you ask: Does the C code use mutexes, spinlocks, or atomic operations when accessing the shared memory? The answer changes the recommendation: if it does, you may only need to ensure compatible locking protocols; if it does not, you must add Rust‑side synchronization as outlined.