<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Concurrency on Pi Stack</title>
    <link>https://www.pistack.xyz/tags/concurrency/</link>
    <description>Recent content in Concurrency on Pi Stack</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 21 Jun 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.pistack.xyz/tags/concurrency/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Self-Hosted Coroutine Libraries: libaco vs greenlet vs libco vs boost::context — Asymmetric Coroutines for High-Concurrency C/C&#43;&#43; Systems</title>
      <link>https://www.pistack.xyz/posts/2026-06-21-coroutine-libraries-libaco-greenlet-libco-boost-context/</link>
      <pubDate>Sun, 21 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://www.pistack.xyz/posts/2026-06-21-coroutine-libraries-libaco-greenlet-libco-boost-context/</guid>
      <description>&lt;h2 id=&#34;why-coroutines-matter-for-high-concurrency-systems&#34;&gt;Why Coroutines Matter for High-Concurrency Systems&lt;/h2&gt;&#xA;&lt;p&gt;Traditional multi-threaded programming with one OS thread per task hits a scalability wall: each thread consumes 8-16 MB of stack space and incurs kernel scheduling overhead. At 10,000 concurrent connections, thread stacks alone consume 80-160 MB of memory. At 100,000 connections, the overhead becomes prohibitive. Coroutines solve this by multiplexing thousands of logical tasks onto a small number of OS threads — each coroutine uses only kilobytes of state rather than megabytes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Actor Model Frameworks for Distributed Systems: Orleans vs Akka.NET vs ProtoActor vs CAF</title>
      <link>https://www.pistack.xyz/posts/2026-06-20-actor-model-frameworks-orleans-akkanet-protoactor-caf/</link>
      <pubDate>Sat, 20 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://www.pistack.xyz/posts/2026-06-20-actor-model-frameworks-orleans-akkanet-protoactor-caf/</guid>
      <description>&lt;h2 id=&#34;what-is-the-actor-model&#34;&gt;What Is the Actor Model?&lt;/h2&gt;&#xA;&lt;p&gt;The Actor Model is a mathematical model for concurrent computation that treats &amp;ldquo;actors&amp;rdquo; as the universal primitives of computation. Each actor can make local decisions, create more actors, send messages, and determine how to respond to the next message received. The model naturally handles concurrency without locks, making it ideal for building distributed systems.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Self-Hosted Lock-Free Data Structure Libraries: concurrentqueue vs ReaderWriterQueue vs Boost.Lockfree (2026)</title>
      <link>https://www.pistack.xyz/posts/2026-06-20-lock-free-data-structure-libraries-concurrentqueue-readerwriterqueue-boost/</link>
      <pubDate>Sat, 20 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://www.pistack.xyz/posts/2026-06-20-lock-free-data-structure-libraries-concurrentqueue-readerwriterqueue-boost/</guid>
      <description>&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;When building self-hosted services that need to process millions of events per second, traditional locking primitives like &lt;code&gt;std::mutex&lt;/code&gt; become the bottleneck. A single contended mutex can reduce throughput by 80-90% compared to a well-designed lock-free alternative. For C++ developers building trading engines, game servers, network proxies, and real-time data processors, lock-free data structures are not an optimization — they&amp;rsquo;re a requirement.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Self-Hosted Lock-Free Concurrent Data Structures: crossbeam vs Disruptor vs Folly vs concurrency-kit</title>
      <link>https://www.pistack.xyz/posts/2026-06-19-lockfree-concurrent-data-structures-crossbeam-disruptor-folly-ck/</link>
      <pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://www.pistack.xyz/posts/2026-06-19-lockfree-concurrent-data-structures-crossbeam-disruptor-folly-ck/</guid>
      <description>&lt;h2 id=&#34;the-lock-free-programming-paradigm&#34;&gt;The Lock-Free Programming Paradigm&lt;/h2&gt;&#xA;&lt;p&gt;Traditional concurrent programming relies on mutexes and locks to protect shared data. When one thread holds a lock, all other threads must wait — leading to contention, priority inversion, and in the worst case, deadlocks. Lock-free data structures eliminate these problems by using atomic CPU instructions (compare-and-swap, fetch-and-add) to allow multiple threads to operate on shared data simultaneously without ever blocking each other.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Self-Hosted Object Pool Libraries in Go: ants vs pond vs bytebufferpool vs conc</title>
      <link>https://www.pistack.xyz/posts/2026-06-19-self-hosted-go-object-pool-libraries-ants-pond-bytebufferpool-conc/</link>
      <pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://www.pistack.xyz/posts/2026-06-19-self-hosted-go-object-pool-libraries-ants-pond-bytebufferpool-conc/</guid>
      <description>&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;Go&amp;rsquo;s goroutines are lightweight, but spawning thousands of them without bounds can still exhaust memory and degrade performance. Object pool libraries solve this by pre-allocating resources and reusing them — reducing GC pressure, bounding concurrency, and improving throughput in self-hosted Go services.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
