<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Memory Ordering on Nalar</title>
    <link>https://nalar.dev/tags/memory-ordering/</link>
    <description>Recent content in Memory Ordering on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/memory-ordering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Memory Fences Constrain Cross-Core Memory Ordering</title>
      <link>https://nalar.dev/memory-fences-constrain-cross-core-memory-ordering/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/memory-fences-constrain-cross-core-memory-ordering/</guid>
      <description>&lt;h1 id=&#34;memory-fences-constrain-cross-core-memory-ordering&#34;&gt;Memory Fences Constrain Cross-Core Memory Ordering&lt;/h1&gt;&#xA;&lt;p&gt;A processor can execute memory operations with more freedom than source-code order suggests. Loads may begin early, stores may wait in buffers, cache-coherence traffic may complete at different times, and independent operations can overlap. These techniques improve throughput, but concurrent software needs precise rules for publishing and observing shared state.&lt;/p&gt;&#xA;&lt;p&gt;A memory fence places an ordering constraint around selected memory operations. It does not normally flush every cache, serialize the entire processor, or make all cores execute one instruction stream. Its role is narrower: it restricts which memory-order outcomes are permitted across a defined boundary.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
