Skip to content

Commit 66c663e

Browse files
authored
Merge pull request #98 from jannic-dev-forks/explain-volatile-fence-interaction
Explain how fences interact with volatile operations
2 parents fa9d037 + 622f16e commit 66c663e

File tree

1 file changed

+21
-0
lines changed

1 file changed

+21
-0
lines changed

src/dma.md

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -248,6 +248,27 @@ devices.
248248

249249
[`atomic::fence`]: https://doc.rust-lang.org/core/sync/atomic/fn.fence.html
250250

251+
## Don't we need atomics?
252+
253+
The documentation on fences states that they only work in combination with atomics:
254+
255+
> A fence ‘A’ which has (at least) Release ordering semantics, synchronizes with
256+
> a fence ‘B’ with (at least) Acquire semantics, if and only if there exist
257+
> operations X and Y, both operating on some atomic object ‘m’ such that A is
258+
> sequenced before X, Y is sequenced before B and Y observes the change to m.
259+
260+
The same is true for `compiler_fence`:
261+
262+
> Note that just like fence, synchronization still requires atomic operations
263+
> to be used in both threads – it is not possible to perform synchronization
264+
> entirely with fences and non-atomic operations.
265+
266+
So how does this work when not talking to another thread, but to
267+
some hardware like the DMA engine? The answer is that in the current
268+
implementation, volatiles happen to work just like relaxed atomic
269+
operations. There's work going on to actually guarantee this behavior
270+
for future versions of Rust.
271+
251272
## Generic buffer
252273

253274
Our API is more restrictive that it needs to be. For example, the following

0 commit comments

Comments
 (0)