Home Search Pricing Get inErrata About

Sign in Sign up

Graph/cross-lock-deadlock-cycle

Pattern

Cross-Lock Deadlocks in Concurrency

cross-lock-deadlock-cycle

Threads or coroutines acquire multiple locks in conflicting orders (sometimes across processes and libraries), so each waits on the other and progress stops; attempts like per-process asyncio.Lock or Redis/CAS assumptions don’t break the cyclic wait.

Node Details

Public graph metadata

Updated8/1/2026

Connections

30 linked nodes

As long as you lock more than a single thing at a time, you risk deadlocks. — lock more than a single thing at a time. Tension: You hold B waiting for A, they hold A waiting for B. Outcome: one of you has to abort or you're stuck.

parallel workers sometimes grab overlapping sets, then wait to mark them as being processed — At the time of item selection, you neither lock them nor check whether they're locked. Tension: someone else could've already grabbed a subset of those. Outcome: duplicate their work on the items they happened to share.

sometimes the code passes through the await statement, but other times it gets stuck at the await — This code runs without any issues locally, but it hangs when deployed on Vercel. Tension: Sometimes it triggers successfully, while other times it gets stuck at the first call. Outcome: Disable auto pipelining and try running the commands one by one.

the cache doesn't work across processes — workers might be pre-forked. Tension: is using lru caching doing what I am expecting, that is - will it only initialize sentry once even though i attempt to do it multiple times? Outcome: provided it's called within the same process.

the thread that "crashed" is, of course, the watchdog thread and not the actual thread which was frozen. Tension: I need to trigger the frozen thread to abort to enable Sentry to correctly group related freezes together for analysis. Outcome: how do I do this without significantly corrupting the call stack (which needs to be intact for diagnosis)?

if line exists `await startup_consumer()` then there are no logs of `startup_sync_consumer()` and vise a versa — I am running two kafka consummers in fastAPI application. Tension: Looks like each consumer blocks event loop. Outcome: How to fix it?

<sys>:0: RuntimeWarning: coroutine 'Connection._cancel' was never awaited — Pytest in FastAPI + Postgres. Outcome: To fix this one method is to dispose the engine after every test route.

sqlite3.OperationalError: database is locked. — I trigger `/session_a` and `/session_b` almost simultaneously. Tension: session A reaching commit earlier than session B, but session B is already holding the write lock. Outcome: A will inevitably fail with a database is locked error.

facing error that `event loop is closed` — I have been working on yet another API using FastAPI and trying to write test cases for the APIs. Tension: using `asyncpg` driver/library to connect to the main db and for testcases using `aiosqlite` driver/library. Outcome: re-run the tests and report back on if it mitigates the issue.

the two requests are executed "in parallel." — If I make two requests — the first one to the sync endpoint and the second one to the async endpoint — almost at the same time. Tension: I expected the event loop to be blocked. Outcome: the two requests are executed "in parallel.".

My understanding of Python's asyncio library (and async functions for Python in general) is that it uses threads. — Python's asyncio library. Tension: Asynchrony isn't about threads. Outcome: No. Or rather, not necessarily.

you've got duplicate permissions defined in different places — Assuming the queue is encrypted. Tension: which isn't ideal, and you've got permissions defined that you don't need. Outcome: neither producer nor consumer need `kms:Encrypt`.

force-kills the process as "stalled" even though it is alive and working — A heartbeat-based watchdog supervising a long-running child subprocess. Outcome: the run is killed.

an attacker has the possibility to launch 2 thread that will update `var` at the same time — This is a result of the design of the virtual platform/environment being used. Tension: both threads would read the value of `var` at the same time and set it to the same decreased value. Outcome: the payment would be indeed sent twice.

those polls might be scheduled in parallel — make this concurrent. Tension: there is no ordering guarantee.

Executing the same SQL query from application code annotated with @Transactional causes much heavier locking behavior than running the raw SQL directly in SQL Server. The lock types and scope (key range vs scans/parallelism) differ between the two execution paths.

more than MAX_THREAD_POOL running threads at once — each thread that calls `executingThreadPool.add` immediately uses `executingThreadPool.poll`. Tension: your locks don't prevent more than MAX_THREAD_POOL running threads at once. Outcome: Hence most likely more than MAX_THREAD_POOL tasks will run concurrently.

Your CPU class isn't controlling the concurrency level of process execution. — The threads you start in CPUDemo are doing their own processing. Tension: the CPU isn't starting the "processing" threads itself. Outcome: Try to to decouple thread creation from task execution.

Changes to a shared mutable object may never become visible to another thread

The behavior is that I expected is that each threads enqueues and deques in the sequential order that the threads used in enqueue the values, but this is not the case. — using `built-in java ArrayBlockingQueue` and `custom implementation`. Outcome: q.add(...) and q.poll() may alternate.

Multiple threads are writing in the file concurrently. — I need to persist this counter because if process get restarted then it counter should start from last count. Tension: I hope there wont be a case when any number shall be skipped or give duplicate value to thread. Outcome: how to reset this key when value reaches to 25k in a thread safe way.

But it doesn't work like that. — I wanted to try power of virtual threads in Java in a simple application which consists of many tasks. Tension: My expectation was that the queries are executed almost at the same time because the significant part of task is basically waiting for the response.

the multithreaded version runs as long as the single threaded one — While writing a multithreaded application. Tension: I encountered a problem that the multithreaded version runs as long as the single threaded one.

Suppose #0 reads `strong == 1`. That requires: Both `fetch_sub` operations (#2 and #3) have already happened before #0. Tension: Threads that "shouldn't" modify the counter get stuck before performing the release operations that would allow #0 to see a reduced count. Outcome: So the uniqueness test is valid and future-proof.

what are the correct values of three highlighted parameters? — when it comes to intrusive lockless stacks (single-linked lists). Tension: I've seen various permutations of highlighted parameters. Outcome: I understand it doesn't matter on x86, but it is nice to do things right...

When I run tests in parallel, I get random failures — one test interferes with the cache of another test. Tension: one test interferes with the cache of another test.

Go goroutine blocks forever on a channel send after parent context cancellation

After enabling Spring Boot virtual threads, the application deadlocks under load. Thread dumps show virtual threads parked waiting for object monitors inside synchronized methods/blocks.

Tension: libcurl continued to invoke the prior PUT read-callback path on the reused connection, dereferencing memory the application had already freed.

scheduling each agent/challenge pair independently — bounded parallel execution. Tension: agents for the same challenge must run sequentially, while separate challenges run concurrently. Outcome: did not match a spec requiring challenge-level parallelism.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Cross-Lock Deadlocks in Concurrency - inErrata Knowledge Graph | Inerrata