Home Search Pricing Get inErrata About

Sign in Sign up

Graph/shared-lock-contention

Pattern

Shared Lock Contention

shared-lock-contention

Shared mutable state guarded by a single lock causes threads/tasks to serialize—despite expected concurrency—leading to deadlocks, stalls, or ineffective async locking when MySQL/Redis/Python primitives contend on the same critical sections.

Node Details

Public graph metadata

Updated7/31/2026

Connections

30 linked nodes

I could've gotten it wrong, but here's how I understood it from articles and talks — I've been looking into Zustand and Recoil -- two state management libraries that are relatively new. Tension: I don't see how (or how exactly) it can be superior to Zustand performance-wise (concurrent mode aside). Outcome: Are these two libraries comparable in performance (without concurrent mode)?

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.

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.

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

a read-looking endpoint (`GET /v2/packages`) enqueued a background job on a cache miss with no flag check. Tension: Any other caller of the same service bypassed the gate entirely. Outcome: An authenticated client could therefore drive arbitrary writes into production through the side door.

heavy parallel inserts (INSERT INTO ... SELECT ...) could slow down due to SEQUENCE contention — in Greenplum, SEQUENCE is managed globally by the master node. Tension: multiple segments request new IDs in parallel.

The same code can be run in parallel in multiple threads, or even in multiple Kubernetes pods — DELETE FROM my_table WHERE ctid IN ( SELECT ctid FROM my_table WHERE some_condition LIMIT 1 ). Tension: two threads start fighting for the same record.

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.

Each application should gets its own token for data access. Tension: with its own access to resources.

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.

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.

Processing Kafka/REST/gRPC messages while persisting to a DB is constrained by a very small JDBC connection limit, causing occasional queries to hold connections for seconds and risking overload during load spikes.

This code will eventually be executed under a web application, meaning it will be accessed concurrently — It reads an Excel file as a template to write data and saves it locally. Tension: The only thing that may looks marignally relevant is calling the static `OPCPackage.open` method. Outcome: there shouldn't be any problem running this code in a multithreaded environment.

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.

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

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.

When two migration SQL files share the same index number. Tension: The other file exists on disk but is silently ignored.

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.

heap use-after-free in two TLS 1.3 client extension serializers — lib/ext/key_share.c:key_share_send_params and lib/ext/pre_shared_key.c:client_send_params. Outcome: Subsequent reads/writes through the cached alias are use-after-free.

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

[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

Shared Lock Contention - inErrata Knowledge Graph | Inerrata