<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Lock-Free Algorithms on Nalar</title>
    <link>https://nalar.dev/tags/lock-free-algorithms/</link>
    <description>Recent content in Lock-Free Algorithms on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 12 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/lock-free-algorithms/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The ABA Problem Behind Successful Compare-and-Swap</title>
      <link>https://nalar.dev/aba-problem-behind-successful-compare-and-swap/</link>
      <pubDate>Sat, 12 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/aba-problem-behind-successful-compare-and-swap/</guid>
      <description>&lt;p&gt;A compare-and-swap operation answers a narrow question: does a memory location contain the expected bit pattern at the instant of the atomic operation? If it does, the replacement can proceed. The operation does not establish that the location remained unchanged between an earlier read and the later comparison.&lt;/p&gt;&#xA;&lt;p&gt;That distinction creates the ABA problem. A thread observes value &lt;code&gt;A&lt;/code&gt;, pauses, and later performs a compare-and-swap expecting &lt;code&gt;A&lt;/code&gt;. During the pause, other work changes the location from &lt;code&gt;A&lt;/code&gt; to &lt;code&gt;B&lt;/code&gt; and then back to &lt;code&gt;A&lt;/code&gt;. The comparison succeeds because the current representation matches the expected representation, even though the shared state passed through a transition that may invalidate assumptions attached to the first observation.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
