<?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 Kai Striega</title><link>http://kaistriega.com/tags/concurrency/</link><description>Recent content in concurrency on Kai Striega</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 25 Jul 2026 14:01:54 +1000</lastBuildDate><atom:link href="http://kaistriega.com/tags/concurrency/index.xml" rel="self" type="application/rss+xml"/><item><title>False Sharing</title><link>http://kaistriega.com/blog/mechanical-sympathy/false-sharing/</link><pubDate>Sat, 25 Jul 2026 14:01:54 +1000</pubDate><guid>http://kaistriega.com/blog/mechanical-sympathy/false-sharing/</guid><description>&lt;p&gt;&lt;a href="https://kaistriega.com/blog/mechanical-sympathy/array-of-structs-vs-struct-of-arrays/"&gt;Part one&lt;/a&gt; of this series had one central fact and one piece of advice. The fact was that memory moves
in 64 byte cache lines, so the cost of a loop is the number of lines it touches. The advice that fell out of
it was to pack your data tightly, because packing more useful bytes into each line means fetching fewer lines.&lt;/p&gt;
&lt;p&gt;This post is about a case where packing tightly is the entire bug, and the fix is to deliberately waste 56
bytes out of every 64.&lt;/p&gt;</description></item><item><title>Processes, Threads, Oh My!</title><link>http://kaistriega.com/blog/low-level-fundamentals/processes-threads-oh-my/</link><pubDate>Sun, 27 Oct 2024 13:51:52 +1100</pubDate><guid>http://kaistriega.com/blog/low-level-fundamentals/processes-threads-oh-my/</guid><description>&lt;h2 id="tldr"&gt;TLDR&lt;a class="headerlink" href="#tldr" title="Link to this heading"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Processes and threads are an integral part of programming&lt;/li&gt;
&lt;li&gt;They are an essential tool in any developer&amp;rsquo;s toolbox&lt;/li&gt;
&lt;li&gt;Processes is how the OS represents a running program.&lt;/li&gt;
&lt;li&gt;Threads are how the computer groups together instructions from your program and executes them&lt;/li&gt;
&lt;li&gt;You can have multiple processes and threads&lt;/li&gt;
&lt;li&gt;At least one thread runs &lt;em&gt;inside&lt;/em&gt; each process&lt;/li&gt;
&lt;li&gt;Tradeoffs of processes vs threads are:
&lt;ul&gt;
&lt;li&gt;Processes are slower to create than threads&lt;/li&gt;
&lt;li&gt;Processes own their memory, threads share memory between them&lt;/li&gt;
&lt;li&gt;It is easy to make very difficult to debug errors with threads&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;a class="headerlink" href="#introduction" title="Link to this heading"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;I have a friend who is currently trying to transition into software engineering. She is currently completing her masters
in IT. While nerding out together about tech, I mentioned multiprocessing. She said she&amp;rsquo;d never heard of it. That&amp;rsquo;s not
great, so I tried to explain it, but feel that I didn&amp;rsquo;t do a great job of it. This blog post will be my attempt to
clarify some of the essential concepts that a developer should know about processes and threads, focusing on how they
work in Linux. I&amp;rsquo;ll do this in a couple of parts:&lt;/p&gt;</description></item></channel></rss>