# Concurrent Programming Published articles for Concurrent Programming. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Fun with Algebraic Effects - from Toy Examples to Hardcaml Simulations DevFeed: [Fun with Algebraic Effects - from Toy Examples to Hardcaml Simulations]() Original publisher: [Read original article]() Author: Fu Yong Quah Published: 2026-01-06T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [OCaml](), [Library](), [Simulation](), [Concurrent Programming]() Tags: [blog](), [blog-post](), [code](), [concurrent-programming](), [libraries](), [library](), [ocaml]() ### AI overview The article describes porting Jane Street's Hardcaml_step_testbench library from monads to algebraic effects in OCaml 5. It explains algebraic effects, compares them with monads, and demonstrates how to use them with the Handled_effect library for Hardcaml simulations. ### Source excerpt I recently ported the Hardcaml_step_testbench library, one of the libraries that we use at Jane Street for Hardcaml simulations, from using monads to using algebraic effects, a new OCaml 5 feature. This blog post walks through what algebraic effects are, why you should consider using them in lieu of monads, and how to actually work with them using the Handled_effect library. One thing I've come to believe is that most of what can be done with monads can be done with algebraic effects in a much more elegant way. ## How to deadlock Tokio application in Rust with just a single mutex DevFeed: [How to deadlock Tokio application in Rust with just a single mutex]() Original publisher: [Read original article]() Author: Piotr Jastrzebski Published: 2024-09-02T00:00:00Z Content type: tutorial Language: en Sources: [Turso Blog]() Topics: [Tokio](), [Deadlock]() Tags: [concurrent-programming](), [deadlock](), [how-to](), [rust](), [tokio](), [turso]() ### AI overview A Tokio-based Rust program deadlocks when a synchronous task holds a std::sync::Mutex while blocking on a future. The article recommends tokio::sync::Mutex for this asynchronous scenario and cautions against premature optimization. ### Source excerpt Battlefield story of how we managed to deadlock Tokio program with just a single mutex ## Ep. 1: Defending Against Memory Breaches: Exploring Rust and Go's Safety Mechanisms DevFeed: [Ep. 1: Defending Against Memory Breaches: Exploring Rust and Go's Safety Mechanisms]() Original publisher: [Read original article]() Published: 2024-04-15T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Rust](), [Memory Safety](), [Go Language](), [Programming](), [Security]() Tags: [c](), [concurrent](), [concurrent-programming](), [go](), [golang](), [languages](), [memory-breaches](), [memory-management](), [memory-safety](), [rust](), [safety](), [safety-mechanism](), [security](), [synchronization]() ### AI overview This introductory video examines memory safety in programming languages, focusing on Rust and comparing its approach with Go, Java, and C. It discusses buffer overflows, memory leaks, data races, static analysis, checked arithmetic, and the trade-offs between safety and performance. ### Source excerpt Introduction: Rust's memory safety features are advantageous to Rust developers because they: Ensure robust protection against buffer overflows and underflows, enhancing the reliability and security of software. Empower developers to manage type coercion effectively, promoting code reliability and safety while facilitating safe type conversions. Provide confidence in writing concurrent code by enforcing strict mutability rules and synchronization, thereby preventing data race issues and ensuring code correctness and efficiency. With these memory safety features deeply integrated into Rust's design, developers can build more reliable, secure, and efficient software, spanning various aspects of memory management, type handling, and concurrent programming paradigms. ## Swift Concurrency Waits for No One DevFeed: [Swift Concurrency Waits for No One]() Original publisher: [Read original article]() Published: 2023-12-22T00:00:00Z Content type: article Language: en Sources: [Saagar Jha]() Topics: [Swift](), [Concurrency](), [Concurrent Programming](), [Code](), [API](), [POSIX]() Tags: [api](), [code](), [concurrency](), [concurrent-programming](), [posix](), [swift](), [threads]() ### AI overview The article explains why Swift Concurrency requires careful handling when asynchronous work must be invoked from synchronous code and then awaited. It uses the example of spawning a Task and blocking with a semaphore to illustrate the complexity of preserving task forward progress, while contrasting Swift Concurrency with older concurrency APIs. ### Source excerpt There was once a master engineer who lived by herself in a mystical, far off place, where nourishment flowed freely and the dirt beneath your feet was more valuable than gold. Inaccessible even by foot, only very few could make the trip for a chance at receiving her wisdom. A novice programmer, enthusiastic but still wet behind the ears, visited her one day. "I have read your code," he began, "and I can only describe it as sublime. But, I've been learning a lot about Swift Concurrency and I see that you don't use it all the time. Why is that?" The master engineer replied promptly with a question of her own: "Tell me, how would an asynchronous program call synchronous code?" "That's easy," he replied. "You can just call it directly." "Now, how would one invoke asynchronous code from a synchronous context?" "Spawn a Task, obviously!" replied the novice engineer, glad that his studies had come in handy. The master engineer smiled. "Very good. But now, imagine waiting for the work to complete before proceeding. What then? The API, naturally, is provided by the system and cannot be redesigned." This troubled the novice, and he furrowed his brow in concentration for some time. Finally, a half-forgotten memory came back to him: "DispatchSemaphore! I can use a semaphore to wait for the asynchronous work!" "Swift Concurrency requires tasks to make forward progress", responded the master engineer. Then she fell silent. After a while, the novice was enlightened. ## Concurrent Programming in Kotlin: Ensuring Thread Safety with Mutex DevFeed: [Concurrent Programming in Kotlin: Ensuring Thread Safety with Mutex]() Original publisher: [Read original article]() Author: Kwabena Bio Berko Published: 2023-07-18T03:33:24Z Content type: tutorial Language: en Sources: [Engineering at Premise - Medium]() Topics: [Kotlin](), [Concurrent Programming](), [Coroutines](), [Database](), [Software Engineering]() Tags: [atomic](), [code](), [component](), [concurrency](), [concurrent](), [concurrent-programming](), [coroutine](), [coroutines](), [data](), [database](), [engineering](), [function](), [implementation](), [io](), [issue](), [kotlin](), [let](), [mobile-app-development](), [mutex](), [safety](), [suspend](), [thread]() ### AI overview This Kotlin tutorial explains how Mutex provides mutual exclusion when multiple threads or coroutines call a refresh function. It shows how locking can prevent duplicate network and database operations, avoid race conditions, and preserve atomicity, while withLock can suspend callers until the current lock is released. ### Source excerpt By Kwabena Bio Berko, Android Engineer Photo by Chris Ried on Unsplash I have recently been experimenting with mutual exclusion(Mutex), a concept in software engineering to solve race conditions when accessing shared resources. Let's assume we have a component with a refresh function that can be accessed from multiple threads or coroutines: https://medium.com/media/e19aa2a9d57bc105b841d28061a199b8/href In the implementation of this component, the function retrieves data from a remote resource and inserts it into the local database. However, these operations need to be atomic. Now, imagine if 10 threads call this function simultaneously, or even a few milliseconds apart. What happens? If you guessed that we make 10 network calls and 10 database IO operations to save the items, then you would be right, as confirmed by the below test: https://medium.com/media/9b279658dbf87021068ee21a913dc80e/hrefhttps://medium.com/media/81cdc164ad807fd45df77389c00bd4cc/href But that's not what we want. It's definitely not resource-friendly. To address this issue, we can use a Mutex. As the name suggests, a Mutex provides mutual exclusion for a specific portion of your code, imposing restrictions on the access to that portion in situations where multiple threads or coroutines may attempt to access it concurrently. In essence, Mutex allows only one thread or coroutine to work within the confines of that portion of the code at any given time. By introducing a Mutex in our refresh function, we can ensure that only one thread is executing the critical sections of the code, preventing race conditions and ensuring atomicity of the operations. https://medium.com/media/9d88a802b4c73f14ceb4d5527158af5d/href In the example above, whenever the refresh function is called, we check to see if the Mutex is already locked or been used. If not, we lock it and then perform our network call and save the results in our local database. This means that whenever another thread or coroutine calls this refresh ## Leveraging the Semaphore concept in Coroutines to limit the parallelism 🔀 DevFeed: [Leveraging the Semaphore concept in Coroutines to limit the parallelism 🔀]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2022-04-01T12:57:35Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [kotlin-coroutines](), [Kotlin](), [Concurrency](), [Concurrent Programming]() Tags: [android](), [concurrency](), [concurrent-programming](), [coroutines](), [how-to](), [java](), [kotlin](), [kotlin-coroutines](), [multithreading](), [mutex](), [synchronization](), [threads]() ### AI overview A tutorial explaining semaphores in Kotlin coroutines, including binary and counting semaphores, and how permits limit parallel access to shared resources. ### Source excerpt Explore the concept of Semaphores in Kotlin Coroutines. Learn how to limit parallelism and manage resource access in concurrent programming. ## Concurrent programming, with examples DevFeed: [Concurrent programming, with examples]() Original publisher: [Read original article]() Published: 2020-03-23T00:00:00Z Content type: article Language: en Sources: [Joe Nelson]() Topics: [Concurrency](), [Concurrent Programming](), [API](), [Programming]() Tags: [api](), [concurrency](), [concurrent](), [concurrent-programming](), [posix](), [thread]() ### AI overview An introductory article on concurrent programming that explains concurrency versus parallelism and covers threading and locking as practical techniques for building concurrent software. It introduces POSIX threads and discusses how concurrency can benefit from hardware parallelism, including limitations imposed by global interpreter locks in Ruby MRI and CPython. ### Source excerpt 2020-03-23 Mention concurrency and you're bound to get two kinds of unsolicited advice: first that it's a nightmarish problem which will melt your brain, and second that there's a magical programming language or niche paradigm which will make all your problems disappear. We won't run to either extreme here. Instead we'll cover the production workhorses for concurrent software - threading and locking - and learn about them through a series of interesting programs. ## Ruby Processes and Threads - Configuring a Web Server DevFeed: [Ruby Processes and Threads - Configuring a Web Server]() Original publisher: [Read original article]() Published: 2019-06-18T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Processes](), [Concurrent Programming](), [Server](), [Rails]() Tags: [api](), [concurrency](), [concurrent-programming](), [cpu](), [database](), [processes](), [rails](), [ruby](), [server]() ### AI overview This article explains how Ruby web servers use threads and processes to handle concurrent requests. It covers I/O blocking, Ruby's Global Interpreter Lock, process-based parallelism, and the CPU, memory, and database-connection tradeoffs involved in server configuration. ### Source excerpt Multiple popular Ruby web servers exist. Each Ruby application is different and the ultimate tl;dr for configuring a web server is: it depends. This post will not prescribe one web server or configuration over another and will instead explain internal components most popular servers contain. In order to facilitate more than one request at a time, a Ruby web server implements Threads, Processes, or both. These tools are used to enable concurrency and are beneficial in different ways. Threads Threads in Ruby are a solution for concurrent programming and can alleviate slow downs due to blocking code. This blocking is usually referred to as "I/O" or Input/Output blocking and occurs when a program must reach out for additional information. External API calls, reading from disk, and querying a database are all examples of blocking operations. When using multiple Threads, an application can continue to function while one Thread is waiting. Most Ruby code in the wild is running on MRI (if you're not sure what you're using, there is a good chance this is what you use). Because of this, Ruby Threads are subject to the Global Interpreter Lock or GIL. The GIL prevents any two threads in the same process from running at exactly the same time making true parallelism not possible. Processes One way to allow for true parallelism in Ruby is to use multiple Processes. A Ruby Process is the instance of an application or a forked copy. In a traditional Rails application, each Process contains all the build up, initialization, and resource allocation the app will need. Running multiple Proccesses can enable more efficient usage of some server resources like the CPU but is not without its downsides. Because each process must boot and provision an entire app, memory usage or database connection saturation can become a limiting factor. Tempering the Metal When configuring on a web server, an application's request shape is the most important factor to consider. Web application requests can ## Goroutine Leaks - The Forgotten Sender DevFeed: [Goroutine Leaks - The Forgotten Sender]() Original publisher: [Read original article]() Published: 2018-11-12T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Concurrency](), [Concurrent Programming](), [Memory Leaks](), [Code]() Tags: [ardan-labs](), [blog](), [code-review](), [concurrency](), [concurrent-programming](), [go](), [go-programming](), [golang](), [goroutines](), [memory-leak](), [memory-management](), [performance](), [programming](), [review]() ### AI overview This article explains how goroutine leaks occur in Go concurrent programs. It describes a leak as a goroutine that is expected to terminate but remains blocked indefinitely, keeping its allocated memory for the lifetime of the application, and illustrates how a goroutine waiting on a channel can become unreachable when its calling function returns. ### Source excerpt Introduction Concurrent programming allows developers to solve problems using more than one path of execution and is often used in an attempt to improve performance. Concurrency doesn't mean these multiple paths are executing in parallel; it means these paths are executing out-of-order instead of sequentially. Historically, this type of programming is facilitated using libraries that are either provided by a standard library or from 3rd party developers. In Go, concurrency features like Goroutines and channels are built into the language and runtime to reduce or eliminate the need for libraries. This has created the illusion that writing concurrent programs in Go is easy. You must be cautious when deciding to use concurrency as it comes with some unique side effects or traps if not used correctly. These traps can create complexity and nasty bugs if you're not careful. ## Ruby Threads and ActiveRecord Connections DevFeed: [Ruby Threads and ActiveRecord Connections]() Original publisher: [Read original article]() Published: 2016-02-14T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Concurrent Programming](), [Concurrency](), [Database](), [API]() Tags: [activerecord](), [api](), [concurrent-programming](), [database](), [ruby]() ### AI overview This article explains how Ruby threads can process large datasets concurrently while sharing memory within a process. Using ActiveRecord, it demonstrates batched email validation through an external API and discusses the accumulation of database connections created by spawned threads. ### Source excerpt Processing large data sets is a common problem faced by many production web applications. One solution is to divide the work amongst multiple processes and have each responsible for a single or significantly smaller batch of data. However, this solution is not without its problems. Machine provisioning limitations or financial barriers may invalidate this solution for a very large N. Within the same vein as "divide and conquer" exists another solution, one which requires far fewer parallel processes: Threads. In the Ruby programming language, a Thread is a built-in object for concurrent programming. Unlike independent processes, all Ruby Threads within the same process share memory, enabling each individual Thread to consume or process objects and elements from the same data store. For this example, a database will be queried, results manipulated and finally returned to same database via ActiveRecord. First Pass Given a User model backed by a simple users table: class User < ActiveRecord::Base end class CreateUsersTable < ActiveRecord::Migration def change create_table :users do |t| t.string :first_name t.string :last_name t.string :email t.boolean :validated, default: false t.timestamps null: false end end end The problem to solve is fairly straight forward: All User records that are not already validated should be fetched and an external API hit with their email address for validation, then saved. If a User's email address is not valid, it should be removed. Fast forwarding through time, it can be assumed that a completely serial solution has been written and deemed unsatisfactory. Then, during a second iteration, a bit of concurrent code was written: class UserEmailValidator def self.run User.where(validated: false) .find_in_batches(batch_size: 30) do |user_batch| validate_emails(user_batch) end end def self.validate_emails(user_batch) threads = user_batch.map do |user| Thread.new do email_validator = EmailService.new(user.email) email_validator.validate user.ema ## Building the new SoundCloud iOS application -- Part I: The reactive paradigm DevFeed: [Building the new SoundCloud iOS application -- Part I: The reactive paradigm]() Original publisher: [Read original article]() Published: 2014-07-07T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [iOS](), [reactive](), [Concurrent Programming](), [API](), [Database](), [event driven](), [JSON](), [client](), [Network]() Tags: [api](), [concurrent-programming](), [database](), [http](), [ios](), [json](), [mobile](), [network](), [programming](), [reactive]() ### AI overview This article describes SoundCloud's rewrite of its iOS application and its adoption of the functional reactive paradigm with Reactive Cocoa. It explains how composable event-driven data streams can unify data transformations, error handling, storage mapping, and concurrency management in a mobile API client. ### Source excerpt Recently, SoundCloud launched the new iOS application which was a complete rewrite of the existing iOS application. The Mobile engineering... ## The Essential Leslie Lamport DevFeed: [The Essential Leslie Lamport]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2014-03-30T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Algorithm](), [Concurrent Programming](), [Concurrency](), [Computer science]() Tags: [concurrent](), [concurrent-programming](), [programming](), [publications](), [science]() ### AI overview The article recommends selected Leslie Lamport publications, focusing on the bakery algorithm for mutual exclusion in concurrent programming and on the ordering of events in distributed systems using logical clocks. It presents these works as particularly elegant and valuable for understanding computer science. ### Source excerpt The Essential Leslie Lamport Some of my favourite Leslie Lamport publications. After it was announced that Leslie Lamport had won the 2013 A.M. Turing award, the link to his list of publications found popularity on most of the tech-related sites I visit. It's an excellent page, with a long (and growing) list of Lamport's publications, and witty comments by the author on each one. The whole list is worth a read, but can feel overwhelming, so I thought I'd try distill it down it some papers that I feel are really worth reading, if you read nothing else on that page. The criteria are: I like these papers for some reason. I'd probably make a different list if I wrote this post again next week. The algorithm is quite simple. It is based upon one commonly used in bakeries, in which a customer receives a number upon entering the store. The holder of the lowest number is the next one served. In A New Solution of Dijkstra's Concurrent Programming Problem Lamport describes the mutual exclusion problem formally posed by Dijkstra, and presents a solution to it. The bakery algorithm is remarkable. Unlike the earlier solutions, which depended on shared memory locations with fairly restrictive behaviors, the bakery algorithm works without any underlying mutual exclusion. Lamport's invention, or discovery, of this algorithm seems to kicked off a cascade of other solutions. Szymanski's, which seems to have been the first to offer both strong fairness and use of a fixed number of shared variables of a bounded size, is particularly interesting. Why this is worth reading: The bakery algorithm, while not very relevant to today's concurrent software due to changes in memory models, is very simple, very beautiful, and solves a complex problem in an innovative way. It's simply a beautiful piece of computer science. In a distributed system, it is sometimes impossible to say that one of two events occurred first. The relation "happened before" is therefore only a partial ordering of the even ## Disruptor 2.0 Released DevFeed: [Disruptor 2.0 Released]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2011-08-27T08:49:00Z Content type: release Language: en Sources: [Mechanical Sympathy]() Topics: [Concurrent Programming](), [Java](), [Programming]() Tags: [concurrent](), [concurrent-programming](), [dependency](), [disruptor](), [framework](), [graph](), [java](), [performance](), [queue](), [release]() ### AI overview This release article announces Disruptor 2.0, highlighting a cleaner API, renamed event-processing concepts, a DSL for assembling EventProcessor dependency graphs, and substantial performance improvements over queue-based approaches. ### Source excerpt Significantly improved performance and a cleaner API are the key takeaways for the Disruptor 2.0 concurrent programming framework for Java. This release is the result of all the great feedback we have received from the community. Feedback is very welcome and really improves the end product so please keep it coming. You can find the Disruptor project here, plus we have a wiki with links to detailed blogs describing how things work. Naming & API Over the lifetime of the Disruptor naming has been a challenge. The funny thing is that with the 2.0 release we have come almost full circle. Originally we considered the Disruptor as an event processing framework that often got used as a queue replacement. To make it understandable to queue users we adopted the nomenclature of producers and consumers. However the consumers are not true consumers. With this release the consensus is to return to the event processing roots and adopt the following naming changes. Producer -> Publisher Events are claimed in strict sequence and published to the RingBuffer. Entry -> Event Events represent the currency of data exchange through the dependency graph of EventProcessors. Consumer -> EventProcessor Events are processed by EventProcessors. The processing of an event can be read only, but can also involve mutations on which other EventProcessors depend. ConsumerBarrier -> DependencyBarrier Complex graphs of dependent EventProcessors can be constructed for the processing of an Event. The DependencyBarriers are assembled to represent the dependency graph. This topic is the real value of the Disruptor and often misunderstood. A fun example can be seen playing FizzBuzz in our performance tests. The ProducerBarrier was always a one-to-one relationship with the RingBuffer so for ease of use its behaviour has been merged into the RingBuffer. This allows direct publishing into the RingBuffer. DSL Wizard The most complex part of using the Disruptor is the setting up of the dependency graph of EventP