# Locks Published articles for Locks. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Troubleshooting row lock contention in Amazon Aurora PostgreSQL: Part 1 - Understanding row lock contention in PostgreSQL DevFeed: [Troubleshooting row lock contention in Amazon Aurora PostgreSQL: Part 1 - Understanding row lock contention in PostgreSQL]() Original publisher: [Read original article]() Author: Sameer Kumar Published: 2026-09-14T16:02:08Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [Amazon Aurora](), [PostgreSQL](), [Concurrency](), [Monitoring](), [Transactions](), [Amazon CloudWatch](), [Amazon RDS](), [Architecture & Design](), [Extension]() Tags: [advanced-300](), [amazon-aurora](), [amazon-cloudwatch](), [amazon-rds](), [architecture](), [availability](), [concurrency](), [database](), [database-performance](), [extension](), [locks](), [monitoring](), [postgresql](), [production](), [rds-for-postgresql](), [technical-how-to](), [transactions](), [troubleshooting]() ### AI overview This first part of a two-part series explains row lock contention in PostgreSQL and Amazon Aurora PostgreSQL. It covers how concurrent transactions competing for the same rows can reduce throughput and cause timeouts despite healthy CPU and I/O, then introduces PostgreSQL locking internals and monitoring techniques using system views, functions, the pgrowlocks extension, and log_lock_waits. The article notes that the same behavior and investigation approach apply to Amazon RDS for PostgreSQL. ### Source excerpt Row lock contention can collapse database throughput during a flash sale even when CPU and I/O look healthy. In Part 1 of this series, learn how PostgreSQL row locking works and how to monitor lock contention in Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL using system views, the pgrowlocks extension, and the log_lock_waits parameter. ## The Real Python Podcast - Episode #303: Free-Threaded Python's History & uv in Production DevFeed: [The Real Python Podcast - Episode #303: Free-Threaded Python's History & uv in Production]() Original publisher: [Read original article]() Author: Real Python Published: 2026-07-17T12:00:00Z Content type: article Language: en Sources: [Real Python]() Topics: [Python](), [Concurrent Programming](), [Concurrency](), [Wagtail](), [Django](), [Compiler](), [GitHub Copilot CLI](), [Model Context Protocol]() Tags: [article](), [cli](), [github-copilot](), [github-copilot-cli](), [locks](), [mcp](), [podcast](), [production](), [python](), [techniques]() ### AI overview This podcast episode discusses the history of attempts to remove Python's Global Interpreter Lock, the current free-threaded Python approach, and the challenges of running multiple tasks concurrently within one process. It also covers Python community news and projects, including JIT compiler work, GitHub Copilot CLI, MCP server testing, uv in production, Wagtail with Django, Python code quality, and thread-safety techniques. ### Source excerpt How many attempts have been made to remove Python's Global Interpreter Lock (GIL)? How do they compare to the current approach? Christopher Trudeau is back on the show this week with another batch of PyCoder's Weekly articles and projects. ## Handling concurrency on the Web with Web Locks API DevFeed: [Handling concurrency on the Web with Web Locks API]() Original publisher: [Read original article]() Author: Cesar Contreras Published: 2026-07-14T15:36:00Z Content type: tutorial Language: en Sources: [OLX]() Topics: [Concurrency](), [Web](), [API](), [Web Development](), [web applications](), [browser]() Tags: [api](), [browser](), [concurrency](), [locks](), [react](), [resumable-file-upload](), [synchronization](), [web](), [web-applications](), [web-development]() ### AI overview This article explains concurrency on the web through the Web Locks API. It describes an OLX upload scenario involving files up to 20GB, where uploads should resume after a browser or tab is reopened without requiring the user to remain in the web app. It identifies multiple tabs resuming the same upload simultaneously as a cause of duplicate uploads, wasted bandwidth, extra processing costs, and unpredictable progress. ### Source excerpt Image by the_iop from Pixabay Concurrency in programming is the ability to manage and execute multiple tasks or processes at the same time (or appear to), allowing programs to remain responsive and efficient. Think of it like a chef in a busy kitchen: they're not cooking every dish from start to finish sequentially, but instead chopping vegetables while one pan simmers and another bakes; juggling progress on several tasks concurrently. I'm a frontend engineer at OLX working mostly with React and NextJs, but I also came from a background in which I worked primarily in concurrent programs with Java. Creating multi-threaded applications can be a pain, dealing with locks, semaphores... and my favorite... deadlocks (very scary in large codebases). Once I transitioned fully to Web development, I never imagined I would have to deal with scenarios like this, and then here I am writing my first article about it. Web development has turned into a very powerful ecosystem, from the previous era where the web was only about flashy animations using HTML marquee (a bit of sarcasm here 😆), dominated by JQuery, to a really powerful environment where you can use Workers, 2D and 3D animations with WebGL and Canvas, offline capabilities with Service Workers, and the list continues. This is evidence that the Web can now face really complex challenges, and it's just a matter of time before you have to face similar ones. The problem Recently, at OLX, we faced the challenge of working with large file size uploads. Providing the best user experience is tricky when it comes to handling uploads, and most of the real use cases out there require the user to stay in the web app until the upload completes, but we didn't want that. Since we are working with large file sizes (up to 20GB), we want the user to be free and do other stuff while this is uploading, so if the user closes and opens the browser or tab, the upload should continue with no manual intervention. For this, we had to provide a mechani ## Coordinate access to shared resources with a distributed lock built on Temporal Workflows DevFeed: [Coordinate access to shared resources with a distributed lock built on Temporal Workflows]() Original publisher: [Read original article]() Author: Keith Tenzer Published: 2026-06-11T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [locking]() Tags: [distributed](), [lease](), [locking](), [locks](), [recovery](), [resource](), [temporal-concepts](), [workflows]() ### AI overview This guide describes a reusable, durable distributed lock for Temporal Workflows. It models each permit as a short-lived child Workflow, uses Workflow IDs for atomic acquisition, and uses Signals and lease timeouts to release locks and recover orphaned permits. ### Source excerpt This guide details a reusable, durable distributed lock for Temporal Workflows that doesn't rely on an external database, central limiter, or any shared state. ## Database Locking Mechanisms DevFeed: [Database Locking Mechanisms]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-05-19T06:27:39Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [Databases](), [Concurrency](), [Deadlock](), [Transactions](), [SQL](), [Object-relational mapping]() Tags: [concurrency](), [consistency](), [database](), [hibernate](), [locking](), [locks](), [optimistic-locking](), [sql](), [transactions]() ### AI overview This tutorial compares pessimistic and optimistic locking for maintaining data consistency in multi-user applications. Pessimistic locking acquires locks before updates, while optimistic locking detects conflicts at commit time using version numbers or timestamps. The article explains their trade-offs in concurrency, performance, deadlocks, and consistency, and outlines suitable use cases. ### Source excerpt Pessimistic vs Optimistic ## Where SQLite Gives Up - Locks, Writers, and the Single-File Problem DevFeed: [Where SQLite Gives Up - Locks, Writers, and the Single-File Problem]() Original publisher: [Read original article]() Published: 2026-05-12T00:00:00Z Content type: article Language: en Sources: [Gaurav Sarma's Blog]() Topics: [SQLite](), [benchmarking](), [Concurrency](), [file]() Tags: [benchmark](), [concurrency](), [embedded](), [filesystem](), [locks](), [python](), [sql](), [sqlite]() ### AI overview This article examines three production limitations of SQLite: unfair lock acquisition, globally serialized write transactions, and scaling constraints from its single-file, single-machine design. It uses small benchmarks and compares these trade-offs with the server-based deployment costs of Postgres and MySQL. ### Source excerpt . [Where SQLite Gives Up](where-sqlite-gives-up-cover... ## Safe Optimistic Lock Coupling DevFeed: [Safe Optimistic Lock Coupling]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2026-04-29T10:22:56Z Content type: article Language: en Sources: [Database Architects]() Topics: [Concurrency](), [Concurrent Programming](), [Data structures](), [Scalability](), [race-condition]() Tags: [concurrent](), [cpu](), [data-structures](), [locking](), [locks](), [mutex](), [performance](), [race-condition](), [scalability](), [synchronization](), [thread](), [typesafety]() ### AI overview The article explains how lock coupling can limit the scalability of concurrent binary-tree lookups because readers contend on locks, especially at the root. It presents Optimistic Lock Coupling, in which readers validate version numbers without writes, and discusses the race-condition risk when values are used before validation. ### Source excerpt As the number of CPU cores keeps growing, the scalability of concurrent data structures becomes increasingly important. A data structure that works fine on 4 cores can become a bottleneck on 32, not because of algorithmic limitations, but because of how it synchronizes access. We illustrate that with a simple binary tree. Usually these data structures are protected by some kind of lock: struct Node { mutex lock; key_type key; value_type value; Node* left, *right; }; struct Tree { mutex lock; Node* root; }; When searching a value, we can traverse the data structure, lock the parts of the data we are currently touching, and release locks when we are done ("lock coupling"): option Tree::lookup(key_type key) { lock.lock_shared(); mutex* currentLock = &lock; Node* iter = root; option result; while (iter) { if (key == iter->key) { result = iter->value; break; } Node* next = (key < iter->key) ? iter->left : iter->right; if (next) next->lock.lock_shared(); currentLock->unlock(); currentLock = next ? &next->lock : nullptr; iter = next; } currentLock->unlock(); return result; } While conceptually simple, lock coupling has quite poor performance in practice. The problem is that it creates contention on the locks, in particular for the root node. Every lookup goes through the root node, thus the root node is constantly locked and unlocked. While there is no semantic contention between lookups, as all readers can read the root concurrently, there is physical contention on the lock itself, which limits scalability. This can be seen below, with concurrent lookups in a tree of 100,000 elements, executed on a 16-core / 32-thread 9950X3D. Lookup scalability: no locking vs lock coupling This contention problem can be solved by using Optimistic Lock Coupling, a synchronization technique where readers do not perform any writes. The key idea here is that writers lock as usual, and increase a version number when they are done updating. Readers read the version numb ## What Happens to an SQL Query? DevFeed: [What Happens to an SQL Query?]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-03-04T03:14:28Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [SQL](), [Databases](), [Parser](), [syntax]() Tags: [database](), [diagram](), [errors](), [execution](), [locks](), [rollback](), [sql](), [syntax]() ### AI overview This tutorial explains how an SQL query moves through a database. It covers transport and access checks, parsing and optimization into an execution plan, execution through the storage engine, and supporting components such as transactions, locks, buffering, and recovery. ### Source excerpt The Journey Through the DB ## Row Locks With Joins Can Produce Surprising Results in PostgreSQL DevFeed: [Row Locks With Joins Can Produce Surprising Results in PostgreSQL]() Original publisher: [Read original article]() Author: Haki Benita Published: 2026-02-23T22:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [Concurrency](), [Databases](), [Query (disambiguation)]() Tags: [articles](), [concurrency](), [database](), [locks](), [postgresql](), [query](), [sql]() ### AI overview This article explains a PostgreSQL edge case in which row locks used with joins can produce surprising results, including a query returning no rows despite a valid, enforced foreign key. It uses a concurrent car-ownership update scenario and suggests ways to prevent the issue. ### Source excerpt You execute a query that joins two tables with a valid an enforces foreign key and it returns no results. How is it possible? We thought it wasn't possible, but a recent incident revealed an edge case we never thought about. In this article I show how under some circumstances row locks with joins can produce surprising results, and suggest ways to prevent it. ## Fixing SQLite Database Locks in Spring Boot with Connection and Transaction Configuration DevFeed: [Fixing SQLite Database Locks in Spring Boot with Connection and Transaction Configuration]() Original publisher: [Read original article]() Author: Anil Kumar Beesetti Published: 2026-01-30T10:36:55Z Content type: tutorial Language: en Sources: [Rock and Null]() Topics: [Spring Boot](), [SQLite](), [locking](), [jpa](), [optimize]() Tags: [hikaricp](), [jpa](), [locking](), [locks](), [optimize](), [performance](), [spring-boot](), [sqlite]() ### AI overview This tutorial explains how a Spring Boot application using SQLite experienced intermittent database locks and request failures. It attributes the issue to connection pooling and lifecycle settings, then describes configuring HikariCP for a single connection, tightening connection management, enabling leak detection, disabling Open-in-View, and controlling transactions manually. In the reported k6 load test, throughput increased from 1,736 to 11,381 requests in five minutes, success rate rose from 76% to 99%, and failed requests fell from 411 to 1. ### Source excerpt Struggling with intermittent database locks in your Spring Boot and SQLite setup? Learn the specific HikariCP and JPA configurations we used to eliminate production hangs and increase throughput by 6.5x. ## A Deep Dive into Table partitioning Part 5: Partitioning an environment not individual tables DevFeed: [A Deep Dive into Table partitioning Part 5: Partitioning an environment not individual tables]() Original publisher: [Read original article]() Author: Adyen Published: 2025-09-17T10:29:53Z Content type: article Language: en Sources: [Adyen Tech]() Topics: [Databases](), [PostgreSQL](), [Framework]() Tags: [adyen](), [database](), [locks](), [partitioning](), [peformance](), [postgresql](), [table-partitioning]() ### AI overview The fifth article in a table-partitioning series explains why partitioning must account for relationships among tables in a PostgreSQL database, rather than treating tables as standalone. It also recaps earlier lessons about partition maintenance, minimizing locks, and the careful use of default partitions. ### Source excerpt By Derk van Veen, Database Engineer, Adyen If we had known better, this would have been the first blog post about partitioning to publish. The reality is, the first article was published two years and two weeks ago, as I write these opening sentences. So this article will not only give insight into the most important decisions you will have to make when considering your partitioning planning, but as a bonus, it will give some insights into how much it takes to write an article like this. One of my values is sharing knowledge and giving back to the community. I share what I learn and take people along on my journey and investigations into the problems we've faced. For this reason, the previous articles have documented these learnings, and this one is about a lesson we learned a little too late. The Journey so far Up to this point: We've shared the what, why and when to partition in the first blog post. In the second article, we covered how to maintain partitioned tables, as they provide some additional challenges when it comes to adding/removing partitions and managing indexes and foreign keys. Only in the third article did we disclose why we decided to work on our own partitioning framework: the existing partitioning solutions didn't provide us with the tools to minimize locks on tables. Our databases are always up and pressured, and the locks around partitioning were simply impossible to deal with. The key lesson from this article was that the default partition is the root of (almost) all evil regarding table partitioning in PostgreSQL. In the last article, we shared a cool solution to a problem we faced, where the default partition actually became the hero of the story. Yes, default partitions are usually the root of partitioning evil, but they also provide a welcome exception to the rule. Just be very careful with its usage. The Journey Continues... What ingredients can be missing after reading these four articles? You already know all about partitioning tables by ## Optimistic Locking Overview DevFeed: [Optimistic Locking Overview]() Original publisher: [Read original article]() Author: somesh sharma Published: 2025-06-19T09:02:40Z Content type: tutorial Language: en Sources: [Housing.com]() Topics: [Concurrency](), [Transactions](), [Database]() Tags: [concurrency](), [concurrency-control](), [database](), [databases](), [isolation-level](), [locks](), [optimistic-locking](), [retry](), [sql](), [stateless](), [transaction-management](), [transactions]() ### AI overview An overview of optimistic locking as a concurrency-control mechanism for database transactions. It explains how version columns detect conflicting updates, when optimistic locking is suitable, and when transaction isolation may make it unnecessary. ### Source excerpt Optimistic locking is a concurrency control mechanism where we assume that multiple transactions can safely access data without conflict, allowing them to proceed without locking the data upfront. Unlike pessimistic locking, where resources are locked to avoid conflicts, optimistic locking allows transactions to proceed without locks and checks for conflicts only when updating the data. If a conflict is detected (e.g., another transaction has already modified the data), the operation fails, and you can retry it. When Should You Use Optimistic Locking? Optimistic locking is ideal for use in scenarios where: Low contention exists: If it's unlikely that multiple users or processes will try to update the same data at the same time, optimistic locking is a good fit. This is especially true in systems where most operations involve reading data rather than writing it. High read-to-write ratio: If your application is mostly about reading data and writing happens less frequently, optimistic locking helps avoid the overhead of locking rows during reads. Non-critical updates: In cases where it's okay to retry a failed update without much impact, optimistic locking is a good choice. When conflicts arise, either the user or the system can simply retry. Stateless operations: Optimistic locking is suitable in stateless environments where holding onto locks across multiple requests or sessions isn't feasible. Long-running transactions: If your transactions take a long time to complete, holding locks during the entire process isn't feasible. Optimistic locking provides flexibility while still maintaining data integrity. How Optimistic Locking Works in Databases In databases, optimistic locking is usually implemented with a version column. Each row in the database has a version field (like a number or timestamp) that gets updated whenever the row is modified. When updating a record, the database checks if the version in the database matches the version the transaction originally read ## Debugging deadlocks in Postgres DevFeed: [Debugging deadlocks in Postgres]() Original publisher: [Read original article]() Author: Louis Heath Published: 2025-02-04T21:37:00Z Content type: tutorial Language: en Sources: [The incident.io Blog]() Topics: [Deadlock](), [debugging](), [Concurrency](), [backend-development](), [Transactions](), [Database]() Tags: [backend-development](), [concurrent](), [database](), [deadlock](), [debugging](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [locks](), [outage](), [post-mortem](), [slack-incident](), [sync](), [transactions]() ### AI overview This article explains how deadlocks arise in Postgres when concurrent processes hold locks that each other needs. It recommends redesigning transactions to acquire locks in a consistent order and discusses alternative approaches that reduce parallelism and may increase lock timeouts. ### Source excerpt Deadlocks are a natural hurdle in backend development, but with a bit of digging and careful design they can be identified and resolved. ## Leader Election With S3 Conditional Writes DevFeed: [Leader Election With S3 Conditional Writes]() Original publisher: [Read original article]() Published: 2024-08-26T08:15:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Amazon S3](), [distributed-systems](), [Kafka](), [API](), [Filesystems](), [JSON]() Tags: [amazon-s3](), [aws](), [data](), [distributed](), [distributed-systems](), [json](), [kafka](), [locking](), [locks](), [object-storage](), [s3]() ### AI overview This article explains how to implement leader election for distributed workloads using Amazon S3 conditional writes. Nodes compete to create a lock file, and a new file is used for each leadership epoch because conditional writes do not prevent lost updates to existing files. ### Source excerpt Table of Contents The Algorithm Obtaining the Lock Expiring a Lock Lock Validity Fencing Off Zombies In distributed systems, for instance when scaling out some workload to multiple compute nodes, it is a common requirement to select a leader for performing a given task: only one of the nodes should process the records from a Kafka topic partition, write to a file system, call a remote API, etc. Otherwise, multiple workers may end up doing the same task twice, overwriting each other's data, and worse. ## Postgres Bloat Minimization DevFeed: [Postgres Bloat Minimization]() Original publisher: [Read original article]() Author: Pavel Borisov Published: 2024-04-26T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Database](), [Transactions](), [Supabase]() Tags: [cli](), [database](), [filesystem](), [locks](), [postgres](), [speed](), [transactions]() ### AI overview This article explains how Postgres stores table data in heap files and how updates create multiple row versions until vacuum or autovacuum removes obsolete versions. It describes free-space and visibility maps, table bloat, aggressive vacuuming, exclusive locks, and pg_repack as an alternative for reclaiming filesystem space. It also mentions checking bloat through the Supabase CLI. ### Source excerpt Understanding and minimizing Postgres table bloat ## Reproducing Chainguard's reproducible image builds DevFeed: [Reproducing Chainguard's reproducible image builds]() Original publisher: [Read original article]() Published: 2023-07-05T00:00:00Z Content type: tutorial Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard images](), [supply-chain-security](), [configuration](), [Tooling]() Tags: [apko](), [attestation](), [build](), [chainguard](), [chainguard-images](), [configuration](), [cosign](), [hardened-images](), [locks](), [reproducibility](), [reproducible-builds](), [secure-image](), [security](), [software-supply-chain](), [supply-chain-security](), [wolfi]() ### AI overview A tutorial explaining how to reproduce a Chainguard Images build using cosign and apko. It describes locking image configurations and notes caveats involving tooling changes and withdrawn packages. ### Source excerpt Learn how to reproduce a Chainguard Images build using cosign and apko. ## MutexProtected: A C++ Pattern for Easier Concurrency DevFeed: [MutexProtected: A C++ Pattern for Easier Concurrency]() Original publisher: [Read original article]() Author: Andreas Kling Published: 2023-04-06T00:00:00Z Content type: tutorial Language: en Sources: [Andreas Kling]() Topics: [C++](), [Concurrency](), [Programming](), [Code](), [Deadlock]() Tags: [c-plus-plus](), [callback](), [class](), [concurrency](), [cpp](), [locks](), [mutex](), [programming](), [serenityos](), [technical](), [type-system]() ### AI overview This tutorial explains the MutexProtected pattern, which combines a mutex and protected data behind a callback-based C++ API. It compares manual locking in C with C++ RAII and the newer pattern, showing how the design reduces forgotten-lock errors and encodes the mutex-data relationship in the type system. It also notes that inconsistent ordering of multiple MutexProtected instances can still cause deadlocks. ### Source excerpt In this post, we will discuss the challenges of programming with locks and how the C++ language offers some useful tools to make it easier. We will start with an example in C and then use C++ to improve upon it in steps. The example APIs are based on real-life APIs from the SerenityOS kernel. ## Handling Concurrency Without Locks DevFeed: [Handling Concurrency Without Locks]() Original publisher: [Read original article]() Author: Haki Benita Published: 2022-06-08T21:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [Concurrency](), [Concurrent Programming](), [Processes](), [Django](), [PostgreSQL](), [Python]() Tags: [articles](), [code](), [concurrency](), [django](), [how-to](), [locks](), [orm](), [postgresql](), [processes](), [python]() ### AI overview A tutorial on recognizing and handling concurrency problems when multiple processes execute code at the same time. It uses a URL shortener built with Python, Django, and PostgreSQL to demonstrate common challenges and approaches that minimize locking. ### Source excerpt Concurrency is not very intuitive - you need to train your brain to consider what happens when multiple processes execute a certain code block at the same time. In this article I present common concurrency challenges and how to overcome them with minimal locking. ## Consensus is Harder Than It Looks DevFeed: [Consensus is Harder Than It Looks]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2020-10-05T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [distributed-systems](), [Concurrent Programming](), [Processes](), [systems](), [Algorithms]() Tags: [complexity](), [concurrency](), [locks](), [processes](), [systems]() ### AI overview The article argues that building consensus-based, highly available systems is harder than the Paxos algorithm alone suggests. It discusses deterministic replicas, concurrency, host failures, leases, monitoring, and the practical challenges of implementing fault-tolerant services. ### Source excerpt Consensus is Harder Than It Looks And it looks pretty hard. In his classic paper How to Build a Highly Available System Using Consensus Butler Lampson laid out a pattern that's become very popular in the design of large-scale highly-available systems. Consensus is used to deal with unusual situations like host failures (Lampson says reserved for emergencies), and leases (time-limited locks) provide efficient normal operation. The paper lays out a roadmap for implementing systems of this kind, leaving just the implementation details to the reader. The core algorithm behind this paper, Paxos, is famous for its complexity and subtlety. Lampson, like many who came after him1, try to build a framework of specific implementation details around it to make it more approachable. It's effective, but incomplete. The challenge is that Paxos's subtlety is only one of the hard parts of building a consensus system. There are three categories of challenges that I see people completely overlook. Determinism "How can we arrange for each replica to do the same thing? Adopting a scheme first proposed by Lamport, we build each replica as a deterministic state machine; this means that the transition relation is a function from (state, input) to (new state, output). It is customary to call one of these replicas a 'process'. Several processes that start in the same state and see the same sequence of inputs will do the same thing, that is, end up in the same state and produce the same outputs" - Butler Lampson (from How to Build a Highly Available System Using Consensus). Conceptually, that's really easy. We start with a couple of replicas with state, feed them input, and they all end up with new state. Same inputs in, same state out. Realistically, it's hard. Here are just some of the challenges: Concurrency. Typical runtimes and operating systems use more than just your program's state to schedule threads, which means that code that uses multiple threads, multiple processes, remote calls, ## On Fair & Scalable Locks DevFeed: [On Fair & Scalable Locks]() Original publisher: [Read original article]() Author: Alimate Published: 2020-03-07T00:00:00Z Content type: tutorial Language: en Sources: [Ali Dehghan - Kemikit]() Topics: [Concurrency](), [Optimization](), [Benchmark](), [cpu]() Tags: [atomic](), [benchmark](), [cpu](), [latency](), [locks](), [optimization](), [threads]() ### AI overview This tutorial explains test-and-set (TAS) locks and test-test-and-set (TTAS) locks, then compares them with a multithreaded benchmark. The supplied text reports that TTAS has better throughput and lower-jitter latency than TAS in that benchmark. ### Source excerpt Let's implement a fair and highly scalable lock! ## Lock Striping DevFeed: [Lock Striping]() Original publisher: [Read original article]() Author: Alimate Published: 2020-01-11T00:00:00Z Content type: tutorial Language: en Sources: [Ali Dehghan - Kemikit]() Topics: [Concurrency](), [Concurrent Programming](), [Data structures](), [implementation]() Tags: [concurrent](), [data-structure](), [implementation](), [locks](), [performance](), [synchronization]() ### AI overview This tutorial explains how to implement a thread-safe concurrent hashtable using plain locks. It covers bucket initialization, resizing, key hashing, updates, and coarse-grained synchronization, while introducing finer-grained synchronization for comparison. ### Source excerpt Let's see how well a fine-grained synchronized concurrent data structure performs compared to its coarse-grained counterpart ## Reader/reader blocking in reader/writer locks DevFeed: [Reader/reader blocking in reader/writer locks]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2019-05-07T15:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Concurrency](), [Concurrent Programming](), [systems]() Tags: [blocking](), [concurrency](), [locks](), [systems](), [thread](), [threads]() ### AI overview The article explains how writer-priority reader/writer locks can cause readers to block behind other readers. When a writer is waiting, new readers cannot acquire the lock until that writer completes, so a long-running reader can trigger severe pauses and throughput loss even under a small write load. ### Source excerpt Abstract In writer-priority reader/writer locks, as soon as a single writer enters the acquisition queue, all future accesses block behind any in-flight reads. Thus, if any readers hold the lock for extended periods of time, this can lead to extreme pauses and loss of throughput given even a very small number of writers. This phenomenon is well-known in certain systems engineering communities (e.g. among some kernel or database developers), but is often surprising when first encountered, and has important implications for the design of such systems. ## Laravel v5.8.6 - v5.8.7 released DevFeed: [Laravel v5.8.6 - v5.8.7 released]() Original publisher: [Read original article]() Author: Laravel Team Published: 2019-03-21T22:35:00Z Content type: release Language: en Sources: [Laravel Blog]() Topics: [Laravel](), [Refactoring]() Tags: [laravel](), [locks](), [refactoring](), [release](), [v5]() ### AI overview Laravel v5.8.6 through v5.8.7 was released with a fix ensuring locks acquired with block() are immediately released when the callback fails, along with a refactoring change. ### Source excerpt Laravel v5.8.6-v5.8.7 is released in 2019/03/21, here are the changes we`ve merged into this release. ## Shard Splits with Consistent Snapshots DevFeed: [Shard Splits with Consistent Snapshots]() Original publisher: [Read original article]() Author: Andrés Taylor Published: 2018-12-04T17:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [vitess](), [MySQL](), [Databases](), [data](), [Algorithm]() Tags: [algorithm](), [customers](), [database](), [databases](), [engineering](), [locks](), [mysql](), [vitess]() ### AI overview This tutorial explains how Square performs gradual MySQL shard splits using Vitess while data continues changing. It covers online cloning, inconsistent destination copies, and consistent snapshots to reduce application impact during the process. ### Source excerpt How to take a copy of something too large to fit in a single shot [Next page]()