Skip to content

Commit bf7a5c4

Browse files
cbeuwRalfJung
andcommitted
Add more backgrounds on lazy store buffers
Co-authored-by: Ralf Jung <[email protected]>
1 parent 6fb7c13 commit bf7a5c4

File tree

1 file changed

+14
-3
lines changed

1 file changed

+14
-3
lines changed

src/concurrency/weak_memory.rs

+14-3
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,18 @@
3030
//! used to make sure a value in a thread's view is not overwritten by a write that occured earlier than the one in the existing view.
3131
//! In our implementation, this is detected using read information attached to store elements, as there is no data strucutre representing reads.
3232
//!
33-
//! Safe/sound Rust allows for more operations on atomic locations than the C++20 atomic API was intended to allow, such as non-atomically accessing
33+
//! The C++ memory model is built around the notion of an 'atomic object', so it would be natural
34+
//! to attach store buffers to atomic objects. However, Rust follows LLVM in that it only has
35+
//! 'atomic accesses'. Therefore Miri cannot know when and where atomic 'objects' are being
36+
//! created or destroyed, to manage its store buffers. Instead, we hence lazily create an
37+
//! atomic object on the first atomic access to a given region, and we destroy that object
38+
//! on the next non-atomic or imperfectly overlapping atomic access to that region.
39+
//! These lazy (de)allocations happen in memory_accessed() on non-atomic accesses, and
40+
//! get_or_create_store_buffer() on atomic accesses. This mostly works well, but it does
41+
//! lead to some issues (https://github.com/rust-lang/miri/issues/2164).
42+
//!
43+
//! One consequence of this difference is that safe/sound Rust allows for more operations on atomic locations
44+
//! than the C++20 atomic API was intended to allow, such as non-atomically accessing
3445
//! a previously atomically accessed location, or accessing previously atomically accessed locations with a differently sized operation
3546
//! (such as accessing the top 16 bits of an AtomicU32). These senarios are generally undiscussed in formalisations of C++ memory model.
3647
//! In Rust, these operations can only be done through a `&mut AtomicFoo` reference or one derived from it, therefore these operations
@@ -156,8 +167,8 @@ impl StoreBufferAlloc {
156167
}
157168
}
158169

159-
/// Gets a store buffer associated with an atomic object in this allocation
160-
/// Or creates one with the specified initial value
170+
/// Gets a store buffer associated with an atomic object in this allocation,
171+
/// or creates one with the specified initial value if no atomic object exists yet.
161172
fn get_or_create_store_buffer<'tcx>(
162173
&self,
163174
range: AllocRange,

0 commit comments

Comments
 (0)