<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.3.3">Jekyll</generator><link href="https://blog.jez.io/feed/concurrency.xml" rel="self" type="application/atom+xml" /><link href="https://blog.jez.io/" rel="alternate" type="text/html" /><updated>2026-01-21T18:17:55-05:00</updated><id>https://blog.jez.io/feed/concurrency.xml</id><title type="html">Jake Zimmerman | Concurrency</title><subtitle>A collection of blog posts about programming, software, types, programming languages, Sorbet, Vim, Markdown, and more.</subtitle><author><name>Jake Zimmerman</name></author><entry><title type="html">Concurrent Programming in ML: A Race</title><link href="https://blog.jez.io/cpml-race/" rel="alternate" type="text/html" title="Concurrent Programming in ML: A Race" /><published>2018-07-18T00:23:23-04:00</published><updated>2018-07-18T00:23:23-04:00</updated><id>https://blog.jez.io/cpml-race</id><author><name>Jake Zimmerman</name></author><category term="sml" /><category term="concurrency" /><summary type="html"><![CDATA[I want to call attention to what I think is a race condition in one of the code listings in the book "Concurrent Programming in ML". The problem is that some of the data isn't protected by a lock, which can lead to a stale read and incorrect behavior. I trace the bad behavior, and propose a fix.]]></summary></entry></feed>