# Deadlock A concurrency condition in which two or more threads or processes wait indefinitely for resources held by one another. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A C++ Exception Handler Retries Without Releasing Deadlock Resources DevFeed: [A C++ Exception Handler Retries Without Releasing Deadlock Resources]() Original publisher: [Read original article]() Author: Remy Porter Published: 2026-08-26T06:30:00Z Content type: opinion Language: en Sources: [The Daily WTF]() Topics: [C++](), [Deadlock](), [Exception](), [Concurrency]() Tags: [c-plus-plus](), [code](), [codesod](), [deadlock](), [exception]() ### AI overview The article examines a C++ exception handler that retries after detecting a deadlock. It explains that the retry mechanism appears to jump back to the start of the block without releasing resources, so it can leave the deadlock unresolved and potentially add more deadlocks. ### Source excerpt Kevin sends us an exception handler from C++. Let's see if we can spot what's going wrong: catch (Exception::Deadlock) { retry; } When we catch a deadlock happening, we retry. That's not a keyword in C++, and looking at how it's used, it has to be some kind of macro, and I suspect that the macro is hiding a goto underneath it. The real problem, though, is that we suspect we're in a deadlock situation. That means this thread is waiting on a resource held by another thread which is waiting for a resource held by this thread. Neither train may continue until the other has passed. So this retry only works if it releases the resource held by this thread (letting the deadlocking thread proceed). But does it? Not according ot Kevin. The code already had a pile of deadlocks in it, so they brought in a highly paid consultant to try and fix them by reordering access and tracing where mutexes were causing issues. This retry just jumps back up to the top of the block, without releasing any resources. It "seems the consultant wanted to add some deadlocks of their own," Kevin says. [Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how! ## Week Ending August 02, 2026 DevFeed: [Week Ending August 02, 2026]() Original publisher: [Read original article]() Published: 2026-08-06T23:45:00Z Content type: news Language: en Sources: [Last Week in Kubernetes Development]() Topics: [Kubernetes](), [bug](), [releases](), [Deadlock]() Tags: [bug](), [cpu](), [deadlock](), [developer](), [kubernetes](), [news](), [releases]() ### AI overview The Kubernetes community roundup covers a Steering Committee candidate Q&A, social media documentation, KCD Around the World, upcoming documentation and release milestones, and fixes for kubelet CPU allocation and StatefulSet reconciliation issues. ### Source excerpt Developer News ## Deadlocks and downtime DevFeed: [Deadlocks and downtime]() Original publisher: [Read original article]() Author: Simeon Griggs Published: 2026-07-08T00:00:00Z Content type: tutorial Language: en Sources: [Blog -- PlanetScale]() Topics: [Database](), [Deadlock](), [Transactions](), [Concurrency](), [Concurrent Programming]() Tags: [database](), [deadlock](), [engineering](), [errors](), [how-to](), [learn](), [postgres](), [reduce](), [transactions]() ### AI overview This article explains how Postgres deadlocks arise when concurrent transactions hold locks that each other needs, and how those deadlocks can escalate into database downtime. It examines the effects of high query volume and immediate retry loops, then recommends consistent row-update ordering, smaller transactions, and late locking to reduce the risk. ### Source excerpt Deadlocks happen when transactions block each other. Learn how they escalate into downtime, how to reduce them through better queries and retry logic, and how Traffic Control can protect your database from your application. ## How Shopify Uses MySQL for Oversell Protection at Scale DevFeed: [How Shopify Uses MySQL for Oversell Protection at Scale]() Original publisher: [Read original article]() Author: Alexandre Zajac Published: 2026-06-22T15:30:09Z Content type: article Language: en Sources: [Hungry Minds]() Topics: [MySQL](), [Database](), [Concurrency](), [Deadlock](), [Redis](), [Transactions]() Tags: [concurrent](), [database](), [deadlock](), [mysql](), [redis](), [transactions]() ### AI overview The article describes Shopify's inventory oversell protection challenge and implementation techniques centered on MySQL, including bounded row pools, composite primary keys, READ COMMITTED isolation, consistent lock ordering, and shadow-mode migration from Redis. It emphasizes concurrency, ACID guarantees, and production-scale reservation handling. ### Source excerpt PLUS: SpaceX buys Cursor for $60B 💰, AWS Blocks framework launch ⚡, Terminal optimization tips 👨💻 ## Monitor SLAs and scale ClickHouse Cloud with clickhousectl and agents DevFeed: [Monitor SLAs and scale ClickHouse Cloud with clickhousectl and agents]() Original publisher: [Read original article]() Author: Al Brown Published: 2026-06-05T14:58:29Z Content type: tutorial Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Cloud](), [monitor](), [Latency](), [Deadlock](), [dashboards](), [Front end]() Tags: [agents](), [clickhouse](), [cloud](), [concurrency](), [cpu](), [frontend](), [guide](), [how-to](), [latency](), [memory](), [monitor](), [resource](), [scale](), [workflow]() ### AI overview This guide shows how to monitor per-workload SLAs in ClickHouse Cloud, investigate latency breaches, scale infrastructure, and delegate remediation to an agent. ### Source excerpt Tag queries to track per-workload SLAs, then use clickhousectl to investigate breaches and scale ClickHouse Cloud, with an agent to remediate. ## Diagnosing a Deadlock in Trino's Hudi Connector That Stalled Blinkit's Inventory Pipeline DevFeed: [Diagnosing a Deadlock in Trino's Hudi Connector That Stalled Blinkit's Inventory Pipeline]() Original publisher: [Read original article]() Author: Ratul Dawar Published: 2026-05-29T09:26:27Z Content type: article Language: en Sources: [Grofers]() Topics: [Deadlock](), [Concurrent Programming](), [Amazon S3]() Tags: [apache-hudi](), [big-data](), [blinkit](), [bug](), [deadlock](), [open-source](), [s3](), [thread](), [trino](), [trinos](), [yield]() ### AI overview Blinkit describes how a deadlock in Trino's Hudi connector stalled inventory replenishment queries without errors or resource saturation. The issue involved one thread pool handling both file-split production and signalling; the reported fix used cooperative scheduling and was contributed upstream. ### Source excerpt A silent deadlock in our query engine was stalling inventory replenishment jobs with no error, no crash -- just infinite waiting. This is the story of how we found it, traced it to an open-source bug, and fixed it upstream. TL;DRTrino's Hudi connector used a single thread pool for both producing file splits and signalling when there was room for more. Under load, every thread ended up waiting for a signal that had no thread left to run it. The fix was to switch the producer side to a cooperative scheduling pattern: yield the thread when the buffer is full, and resume when space opens. Our inventory replenishment pipeline was frozen. CPU was idle. Memory was fine. There were no errors anywhere. Queries just... stopped moving. The first signal was a long queue on one of our analytics clusters. Queries were piling up. Inventory replenishment jobs -- the jobs that decide how much stock every warehouse and store needs to hold -- were delayed. Blinkit's supply chain was being impacted. Dashboards were turning amber, but nothing was crashing. That was the unsettling part. Investigation: Resources Doing Nothing The affected cluster runs analytical workloads on Trino, reading data stored in Apache Hudi tables on S3. The natural first instinct in a queue build-up is to look at resource saturation -- a CPU spike, memory pressure, network bottleneck. There was none of that. The cluster was sitting largely idle, with CPU barely above baseline and heap usage well within limits. Every new query touching a Hudi table joined the queue and stayed there indefinitely. Queries that were already mid-execution completed fine. Only freshly submitted ones were affected. And crucially, there were no errors. No timeouts, no exceptions in the logs -- just silence and a growing backlog. A thread dump -- a snapshot of what every thread in the process is doing right now -- was our next move. It showed dozens of producer threads all stuck in the same parked state, waiting on the exact same internal signal. ## 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 ## GNU/Hurd developments and fixes in Q1 2026 DevFeed: [GNU/Hurd developments and fixes in Q1 2026]() Original publisher: [Read original article]() Published: 2026-03-02T06:07:00Z Content type: news Language: en Sources: [GNU Hurd]() Topics: [GNU/Hurd](), [Linux](), [kernels](), [Debian](), [bug](), [C](), [Deadlock](), [Documentation](), [Claude](), [qemu]() Tags: [2026](), [bug](), [c](), [claude](), [deadlock](), [debian](), [documentation](), [gnu-hurd](), [hardware](), [linux](), [qemu]() ### AI overview A Q1 2026 GNU/Hurd project update reports debugging and fixes across SMP, threading, filesystem, IPC, networking, and related components, along with wiki documentation and hardware-installation guidance. ### Source excerpt Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q1 of 2026! Details. Brent W. Baccala debugged some x86_64 SMP issues with a Claude AI bot. The bot did not contribute any code. It just found some incorrect code that Damien then fixed. It did get some things wrong, but it was incredibly helpful pointing out several problems. You can read its report here. Joshua Branson tweaked the hurd wiki. The most helpful addition is this page, which documents how to flash a working qemu hurd image directly to an HDD or SSD. This is a really easy way to install the Hurd on real hardware! Buy a supported machine from this page and give it a shot! Consider this another reminder that the Hurd project could use more documentation writers. It's an easy way to contribute. As a fun fact, Joshua wrote this qoth on the Hurd running on a T420 with 12 GB of RAM! Running Debian GNU/Hurd on bare metal these days is largely fairly stable. Emacs, i3, netsurf, and luakit all work just fine and most of the Debian package archive compiles without issue on the Hurd. Etienne Brateau fixed a compilation error. He also provided a simple test program that exposed a rather serious threading bug, which Samuel promptly fixed. This is a good reminder that writing simple C test programs that successfully run on Linux, but fail on the Hurd can have a large impact. Gianluca Cannata worked on our httpfs translator. Diego Nieto Cid added a daemon-wait option for console-client. This can help users with slow machines avoid a broken Hurd console. He also fixed a rumpdisk compilation issue. Mike Kelley fixed a deadlock in SMP enabled GNU Mach kernels. He also fixed a page fault in amd64 SMP kernels. He fixed another deadlock in the alarm () function. He fixed a panic when running large builds without the mach-defpager. He also fixed some of our signal related code. He worked with Samuel to investigate an odd bug. Their detailed investigation uncovered and lead to a fix in ## How to Prevent the DB from Becoming a Bottleneck DevFeed: [How to Prevent the DB from Becoming a Bottleneck]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-02-24T08:15:03Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [Databases](), [Back end](), [Latency](), [Concurrency](), [Deadlock](), [Transactions](), [MongoDB](), [MySQL](), [PostgreSQL]() Tags: [concurrency](), [how-to](), [latency](), [locking](), [performance]() ### AI overview This tutorial explains how databases can become application performance bottlenecks even when application code is optimized. It covers diagnosing slow queries with profiling and logs, monitoring execution time and latency, and understanding how locking and deadlocks can affect concurrent transactions. ### Source excerpt Tips and Strategies ## Introducing: Postgres Best Practices DevFeed: [Introducing: Postgres Best Practices]() Original publisher: [Read original article]() Author: Pedro Rodrigues Published: 2026-01-21T07:00:00Z Content type: release Language: en Sources: [Supabase Blog]() Topics: [AI-assisted coding](), [Deadlock](), [cursor](), [GitHub Copilot]() Tags: [agent-skills](), [ai-agents](), [ai-coding](), [best-practices](), [cursor](), [deadlock](), [github-copilot](), [postgres]() ### AI overview Supabase releases Agent Skills that give AI coding agents Postgres best-practice rules for producing correct, high-quality code. ### Source excerpt We are releasing Agent Skills for Postgres Best Practices to help AI coding agents write high quality, correct Postgres code. ## Corrosion DevFeed: [Corrosion]() Original publisher: [Read original article]() Published: 2025-10-22T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [distributed-systems](), [Concurrent Programming](), [Deadlock](), [Rust](), [Network](), [Orchestration](), [fly](), [fly.io]() Tags: [cdn](), [close-to-users](), [deadlock](), [deploy-app-servers](), [distributed-system](), [docker](), [docker-containers](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [outage](), [pipelines](), [postgresql-clusters](), [routing](), [rust](), [servers](), [synchronization]() ### AI overview This article introduces Corrosion, Fly.io's open-source distributed state synchronization and service discovery system. It explains how Fly.io propagates workload and routing state across globally distributed servers and edge proxies, and recounts a severe outage caused by a Rust concurrency bug that triggered a contagious deadlock. The article also describes Fly.io's decentralized orchestration model, in which individual servers are authoritative for their workloads instead of relying on a centralized database. ### Source excerpt Fly.io transmogrifies Docker containers into Fly Machines: micro-VMs running on our own hardware all over the world. The hardest part of running this platform isn't managing the servers, and it isn't operating the network; it's gluing those two things together. Several times a second, as customer CI/CD pipelines tear up or bring down Fly Machines, our state synchronization system blasts updates across our internal mesh, so that edge proxies from Tokyo to Amsterdam can keep the accurate routing table that allows them to route requests for applications to the nearest customer instances. On September 1, 2024, at 3:30PM EST, a new Fly Machine came up with a new "virtual service" configuration option a developer had just shipped. Within a few seconds every proxy in our fleet had locked up hard. It was the worst outage we've experienced: a period during which no end-user requests could reach our customer apps at all. Distributed systems are blast amplifiers. By propagating data across a network, they also propagate bugs in the systems that depend on that data. In the case of Corrosion, our state distribution system, those bugs propagate quickly. The proxy code that handled that Corrosion update had succumbed to a notorious Rust concurrency footgun: an if let expression over an RWLock assumed (reasonably, but incorrectly) in its else branch that the lock had been released. Instant and virulently contagious deadlock. A lesson we've learned the hard way: never trust a distributed system without an interesting failure story. If a distributed system hasn't ruined a weekend or kept you up overnight, you don't understand it yet. Which is why that's how we're introducing Corrosion, an unconventional service discovery system we built for our platform and open sourced. Our Face-Seeking Rake State synchronization is the hardest problem in running a platform like ours. So why build a risky new distributed system for it? Because no matter what we try, that rake is waiting for our foot ## Trip report: Node.js collaboration summit (2025 Paris) DevFeed: [Trip report: Node.js collaboration summit (2025 Paris)]() Original publisher: [Read original article]() Published: 2025-05-22T00:00:00Z Content type: article Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [ci](), [Deadlock](), [JavaScript](), [Memory Safety](), [wasm](), [cross-platform](), [Open Source](), [browsers]() Tags: [browsers](), [ci](), [cross-platform](), [deadlock](), [javascript](), [memory-safety](), [node-js](), [open-source](), [wasm]() ### AI overview A trip report on the 2025 Node.js collaboration summit in Paris, covering CI infrastructure reliability, experimental WASM modules, browser coordination, V8 Oilpan integration, memory safety, garbage collection, mentorship, and contributor experience. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## 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. ## MVCC and serializability in HyPer DevFeed: [MVCC and serializability in HyPer]() Original publisher: [Read original article]() Published: 2024-11-06T00:00:00Z Content type: article Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Database](), [Transactions](), [Concurrency](), [locking](), [Deadlock](), [processing](), [systems]() Tags: [concurrency](), [concurrency-control](), [database](), [deadlock](), [locking](), [mvcc](), [processing](), [transactions]() ### AI overview This article explains Multi-Version Concurrency Control (MVCC), contrasts it with Two-Phase Locking, and introduces MVCC patterns and techniques used in HyPer. It discusses locking phases, deadlocks, cascading rollbacks, and concurrency limitations. ### Source excerpt . [MVCC and Serializability in HyPer](mvcc-and-serializability-in-hyper-cover... ## Fearless Concurrency Ep.4: Understanding Mutexes and Thread Safety in Rust DevFeed: [Fearless Concurrency Ep.4: Understanding Mutexes and Thread Safety in Rust]() Original publisher: [Read original article]() Published: 2024-10-25T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Rust](), [Programming](), [Deadlock]() Tags: [avoiding-race-conditions-in-rust](), [code](), [concurrency](), [concurrency-and-memory-management-in-rust](), [concurrency-in-rust](), [deadlock](), [how-to](), [managing-shared-data-in-rust](), [mutex](), [mutex-and-drop-trait-in-rust](), [mutexes-in-rust](), [rust](), [rust-concurrency-best-practices](), [rust-concurrency-guide](), [rust-drop-trait-in-concurrency](), [rust-multithreading-tutorial](), [rust-mutex-example](), [rust-mutex-vs-lock](), [rust-ownership-and-borrowing-in-concurrency](), [rust-thread-safety](), [rust-thread-safety-without-garbage-collection](), [safety](), [synchronization](), [thread](), [thread-synchronization-in-rust](), [understanding-poisoned-mutexes-in-rust]() ### AI overview This episode explains how Rust's ownership and borrowing rules support thread-safe multithreaded programming. It covers sharing data with mutexes, mutual exclusion, automatic lock cleanup, poisoned mutexes, and how Rust helps prevent data races, undefined behavior, and some deadlock issues. ### Source excerpt Introduction: Welcome to Episode 4 of Fearless Concurrency in Rust! In this episode, we explore how Rust's ownership and borrowing rules impact multithreaded programming, focusing on the complexities of managing memory in a concurrent environment. We'll break down how Rust's strict borrowing and ownership model ensures safety and prevents common pitfalls like data races and undefined behavior, making it an ideal choice for building reliable multithreaded applications. Thread Safety and Ownership: Managing variables across threads using Rust's ownership rules. ## 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 ## Mitigating Deadlocks in high concurrency environments DevFeed: [Mitigating Deadlocks in high concurrency environments]() Original publisher: [Read original article]() Author: Elson Oliveira Published: 2024-08-14T16:31:20Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Deadlock]() Tags: [batch](), [concurrency](), [data](), [mysql](), [performance](), [update]() ### AI overview The article explains how concurrent MySQL upserts can create gap-lock overlaps and deadlocks, and proposes composite primary keys to better align storage with update patterns. ### Source excerpt The problem In order to guarantee data integrity, MySQL requires locks prior to updating existing records. If multiple processes update data in the same table in parallel, deadlocks can occur depending on how the data is stored in disk and managed by MySQL. That can happen even if the different processes target different records. This blog post explores the problem of deadlocks in MySQL while updating data, and illustrates how composite primary keys can effectively mitigate this issue. ## Keycloak 23.0.4 released DevFeed: [Keycloak 23.0.4 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2024-01-08T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [WebAuthn](), [OpenID connect (OIDC)](), [Cross-origin resource sharing (CORS)](), [Deadlock](), [Parsing](), [passwords]() Tags: [cors](), [deadlock](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [migration-guide](), [oidc](), [openid-connect](), [parsing](), [password](), [release](), [saml](), [sso](), [ui]() ### AI overview Keycloak 23.0.4 was released on January 8, 2024. The release provides download and upgrade guidance and lists resolved issues affecting WebAuthn tests, remote session preloading, offline sessions, password visibility styling, administrative APIs, CORS, user-profile scopes, CI label parsing, OIDC logout tokens, and Catalan HTML email links. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Bugs #9693 PubKeySignRegisterTest failures in WebAuthn tests testsuite #24508 Deadlock when pre-loading remote sessions from external Infinispan storage #24763 Remove sign out action for offline sessions admin/ui #25016 Make password visibility css classes configurable for themes login/ui #25096 Meaning of briefRepresentation query parameter is inverted in GroupResource.getSubGroups admin/api #25111 RealmAdminResource.getGroupByPathGroup does not work with space in path parameter admin/api #25120 CORS issue in 'openid-connect/certs' endpoint oidc #25475 User Profile: If required roles ("user") and reqired scopes are set, the required scopes have no effect user-profile #25633 Parsing of labels issue IDs doesn't work with colons and the "fixes" keyword ci #25753 Backchannel logout token is missing the "exp" claim oidc #25878 HTML emails in Catalan don't contain links translations ## Dynamic Table Partitioning in Postgres DevFeed: [Dynamic Table Partitioning in Postgres]() Original publisher: [Read original article]() Author: Michel Pelletier Published: 2023-10-03T07:00:00Z Content type: tutorial Language: en Sources: [Supabase Blog]() Topics: [data](), [Deadlock]() Tags: [concurrency](), [data](), [how-to](), [learn](), [performance](), [postgres](), [scale]() ### AI overview This article explains how dynamic table partitioning can help scale a large Postgres table in place. Using a customer example with 500 million chat messages, it describes how growing indexes, aging data, unrelated rows, vacuuming, and data movement can degrade query performance and complicate migration without downtime. ### Source excerpt Learn how to scale large postgres tables in place and increase query performance. ## A linter I really recommend you to use if you're doing SQL in Golang DevFeed: [A linter I really recommend you to use if you're doing SQL in Golang]() Original publisher: [Read original article]() Author: Piotr Jastrzebski Published: 2023-08-10T00:00:00Z Content type: tutorial Language: en Sources: [Turso Blog]() Topics: [SQL](), [Databases](), [ci](), [GitHub Actions](), [Deadlock](), [Command-line interface]() Tags: [also](), [ci](), [code](), [deadlock](), [github-actions](), [golang](), [sql](), [turso]() ### AI overview This final article in a series about resource leaks in SQL databases with Golang explains how to use the sqlclosecheck linter to detect database resources that are not closed. It demonstrates local usage and integration with GitHub Actions and golangci-lint so the check can run automatically. ### Source excerpt This is a final article of my mini series about the topic of leaking resources when using SQL databases in Golang. The whole series consists of three parts ## How to get your database access code deadlocked in Golang DevFeed: [How to get your database access code deadlocked in Golang]() Original publisher: [Read original article]() Author: Piotr Jastrzebski Published: 2023-07-27T00:00:00Z Content type: tutorial Language: en Sources: [Turso Blog]() Topics: [Deadlock](), [C++]() Tags: [code](), [concurrency](), [database](), [deadlock](), [golang](), [how-to](), [turso]() ### AI overview A Go database/sql deadlock can occur when an error exits a row-processing loop before the rows are closed. The article explains that explicitly closing rows releases a reader lock so a deferred writer-lock operation can proceed. ### Source excerpt Unlike C++ or Rust, Golang is supposed to be a programmer friendly language. Most of the time it does a great job in increasing developer productivity by being a relatively easy programming language... ## What's New in Apache Pulsar 2.7.5 DevFeed: [What's New in Apache Pulsar 2.7.5]() Original publisher: [Read original article]() Author: Jason918, momo-jun Published: 2022-09-09T00:00:00Z Content type: release Language: en Sources: [Apache Pulsar Blog]() Topics: [Apache Pulsar](), [releases](), [bug](), [Release notes](), [Deadlock]() Tags: [apache](), [api](), [bug-fixes](), [contributors](), [deadlock](), [improvements](), [releases]() ### AI overview Apache Pulsar 2.7.5 is the final 2.7.x release, featuring critical fixes for message and data loss, broker deadlocks, connection leaks, proxy failures, and compaction behavior. ### Source excerpt The Apache Pulsar community releases version 2.7.5! 23 contributors provided improvements and bug fixes that delivered 89 commits. Thanks for all your contributions. ## Transactional Memory and Tech Hype Waves DevFeed: [Transactional Memory and Tech Hype Waves]() Original publisher: [Read original article]() Published: 2019-08-14T15:09:26Z Content type: opinion Language: en Sources: [Jessie Frazelle]() Topics: [Concurrency](), [Deadlock](), [Database](), [intel]() Tags: [attacks](), [database](), [deadlock](), [intel](), [side-channel](), [synchronization]() ### AI overview The article explains transactional memory, including Intel's Transactional Synchronization Extensions (TSX), as a way to avoid deadlocks while potentially introducing livelocks. It compares transactional memory with database transactions and discusses speculative outcomes, TSX abort handlers, and possible side-channel security concerns. ### Source excerpt At lunch today I learned about Transactional Synchronization Extensions (TSX) which is an implementation of transactional memory. The conversation started as a rant about why transactional memory is bad but then it evolved into how this concept even came to be and how it even got implemented if it's such a terrible idea. What is transactional memory? First let's start by going over what transactional memory is. You might be familiar with a deadlock. A deadlock occurs when a process or thread is waiting for a specific resource, which is also waiting on a different resource that is being held by another waiting process. You can think of this as P1 needs R1 and has R2, while in turn P2 needs R2 and has R1. That is a deadlock. Transactional memory removes the possibility of getting a deadlock and replaces it with what is known as a livelock. A livelock happens when processes are constantly changing with regard to one another but neither of them move forward or progress in anyway. Imagine you are walking down the street while another person is heading towards you. You move to the right to avoid running into them as they also move in that direction to avoid running into you. You both then move to the other side so as to not run into each other. This repeats over and over again with no progress forward since both people are moving in the same direction. That is a livelock. With transactional memory you no longer have deadlocks but livelocks. Why is this? Well, transactional memory works very similarly to database transactions. A transaction is a group of operations that can execute and commit changes as long as there are no conflicts. If there is a conflict, it will start from state zero and try to run again until there are no conflicts. Therefore, until there is a successful commit of a run, the outcome of any operation is speculative. Intel's implementation of TSX behaves in such a way that when a transaction aborts due to a hardware exception, it does not fire typical e ## Friday Q&A 2017-10-27: Locks, Thread Safety, and Swift: 2017 Edition DevFeed: [Friday Q&A 2017-10-27: Locks, Thread Safety, and Swift: 2017 Edition]() Original publisher: [Read original article]() Author: Mike Ash Published: 2017-10-27T11:28:00Z Content type: article Language: en Sources: [Mike Ash]() Topics: [Swift](), [Concurrency](), [Deadlock](), [Objective-C]() Tags: [concurrent](), [deadlock](), [locks](), [mutex](), [objective-c](), [safety](), [swift](), [thread](), [threading](), [threads]() ### AI overview An updated guide to locks and thread safety in Swift, covering mutex types, their behavior, and related Apple and Objective-C synchronization facilities. ### Source excerpt Back in the dark ages of Swift 1, I wrote an article about locks and thread safety in Swift. The march of time has made it fairly obsolete, and reader Seth Willits suggested I update it for the modern age, so here it is! (Read More) [Next page]()