
<!DOCTYPE html>

<html>

<head>

<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">

</head>

<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">

<p dir="auto">On 2 Jun 2022, at 7:56, Johan via digitalmars-d-ldc wrote:</p>

<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">

<p dir="auto"><code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">atomicFence</code> only works for ordering memory operations on a single thread, not ordering between threads.</p>

</blockquote>

<p dir="auto"><code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">atomicFence</code> should work across threads as well; it inserts actual processor fences as necessary, in addition to the requisite effect on compiler optimisations.</p>

<p dir="auto">However, in practice, code using standalone fences often harder to make sense of than that using atomic loads/stores, unless the relevant accesses are explicitly documented in enough detail. Just sprinkling <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">atomicFence</code> over an existing code base to make it thread-safe is pretty much guaranteed to fail. Thus, preferring atomic loads/stores is very sound advice in practice.</p>

<p dir="auto">(There are also fences that are effectively for compiler optimisations only and usually go by volatile fences or signal fences; perhaps that’s what Johan was thinking of.)</p>

<p dir="auto">— David</p>


</div></div></body>


</html>