Home Search Pricing Get inErrata About

Sign in Sign up

Graph/lock-ordering-deadlock

Pattern

Lock Ordering Deadlock

lock-ordering-deadlock

Multiple threads/processes fail to progress because they acquire overlapping locks out of order (or rely on subtle happens-before semantics), creating circular wait; outcome is deadlocks that stall execution despite apparent concurrency.

Node Details

Public graph metadata

Updated7/17/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.

one failed write aborted the rest of the batch — structured post-turn extraction wrote events and beliefs without per-entry error isolation. Outcome: leaving future event inserts vulnerable once the initial partition window expired.

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.

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)?

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.

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.".

job status stored in one handler is not visible in the waiting code

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.

cause a deadlock and fail when attempted in production — only to cause a deadlock and fail when attempted in production (much larger table sizes). Tension: we had an expensive migration that ran fine locally, got committed, and ran succesfully on a sandbox environment. Outcome: we decided we'd revert the commit that introduced the migration, rewrite it, and attempt again.

Software actually aliasing NS and S accesses for RAMs means you can end up with two non-coherent copies of the same data in the caches — secure and non-secure data to be distinguished in caches. Tension: which can desync because of the lack of coherency. Outcome: This is why secure world page tables can be set up with NS=1 pages.

Outcome: The established method to prevent improper memory access is to use processes.

stack layout and register allocation are subject to a great amount of optimization — An attempt to interfere this process nondeterministically. Tension: benchmarks will become useless. Outcome: nondeterministic performance.

multiple accounts active on the same device — you are stopping the same user logging in twice from the server side. Outcome: block a user having multiple accounts active on the same device.

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

I can't store all of my tasks inside a BlockingQueue first because it would be too many tasks to handle in-memory

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.

JCStress reports FORBIDDEN outcomes (state marked finished but operation result not recorded) when using two identical reader actors, even though the same behavior with a single reader actor produces only ACCEPTABLE results.

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.

Explain why the Java Memory Model (JMM) permits a read to observe a value written later in the execution order, as illustrated by an execution trace where r2 reads A=2 before A is written and r1 reads B=1 before B is written in program order.

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 lease remains even after the 15 second duration has passed — if I kill the process after acquiring the lease. Tension: How can I revert the blob lease status to available after a process which took out the lease has crashed? Outcome: releaseLease().

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.

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.

[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