Lock Ordering Violation Detection Prompt

This prompt is designed for systems engineers and platform teams who need to statically analyze code for lock ordering inconsistencies that can lead to production deadlocks. The primary job-to-be-done is pre-merge risk detection: before a code change ships, you want to know if it introduces a circular wait condition by acquiring locks in a different order than existing code paths. The ideal user is a developer or tech lead reviewing a pull request that touches synchronization logic, or an SRE investigating intermittent deadlocks who needs to map the theoretical lock graph from source code. The prompt expects concrete code snippets containing explicit lock acquire and release operations—such as synchronized blocks in Java, std::mutex::lock in C++, sync.Mutex.Lock in Go, or lock statements in C#. It works best when you can provide multiple functions or methods that each acquire a subset of locks, so the model can build a global ordering graph and detect cycles.

To use this effectively, you must supply the prompt with the relevant code sections, the names of the lock objects involved, and optionally the calling context or thread entry points. The model will produce an ordered lock graph, flag any violations where lock A is acquired before lock B in one path but after lock B in another, and generate a reproduction scenario description that explains the interleaving required to trigger the deadlock. You should not use this prompt as a replacement for runtime lock tracing tools like lockdep in the Linux kernel, Java's built-in deadlock detection, or Go's race detector. Those tools observe actual runtime behavior; this prompt performs static analysis on the code you provide and can miss violations hidden in dynamically dispatched calls, reflection, or code paths you didn't include. It also cannot reason about lock ordering enforced by external systems like database row locks or distributed locks unless you explicitly model those as lock acquisitions in the input.

This prompt is most valuable during pre-merge code review and when auditing critical-path synchronization in performance-sensitive or high-concurrency components. It is not suitable for analyzing lock-free code, channel-based synchronization, or async/await patterns where locks are not explicitly visible. For those cases, use the sibling prompts on goroutine leak detection, channel deadlock analysis, or asynchronous race condition detection. When the prompt identifies a violation, treat the output as a high-signal finding that requires human verification—the model can hallucinate lock relationships if the code is ambiguous or if lock objects are aliased. Always validate the reported violation against the actual code before filing a bug or blocking a merge. For production deadlock investigations, pair this prompt's static analysis output with runtime thread dump analysis to confirm whether the theoretical ordering violation actually manifests under load.

This prompt template is designed to analyze lock acquisition sequences across multiple code paths and detect inconsistent ordering that could lead to deadlocks under concurrent execution. Replace the square-bracket placeholders with your actual code, language context, and output requirements. The prompt works best when provided with complete function bodies or method implementations that acquire multiple locks, not just lock declarations.

codeCopy
You are a systems concurrency analyst. Your task is to detect lock ordering violations in the provided code that could cause deadlocks.

## INPUT
Code to analyze:
```[LANGUAGE]
[CODE_BLOCK]

Additional context about the codebase's locking conventions and known lock types: [CONTEXT]

INSTRUCTIONS

1. Extract every lock acquisition point in the code, noting the lock object, acquisition method (e.g., lock(), synchronized, mutex.Lock()), and the function or method where it occurs.
2. Build a directed graph of lock acquisition order across all code paths. An edge from Lock A to Lock B means Lock A is acquired before Lock B in at least one code path.
3. Identify any cycles in this graph. A cycle indicates a potential deadlock scenario where two or more code paths acquire the same locks in different orders.
4. For each cycle found, trace the exact code paths that create the conflicting orders and describe a concrete interleaving scenario that would trigger the deadlock.
5. Classify each violation by severity: CRITICAL (cycle exists in frequently executed paths with no timeout protection), HIGH (cycle exists but with timeout or try-lock fallback), MEDIUM (potential cycle from indirect lock acquisitions like callbacks or virtual dispatch), LOW (theoretical cycle requiring unlikely interleaving).

OUTPUT SCHEMA

Return a JSON object with this exact structure: { "lock_graph": { "nodes": [{"lock_id": "string", "type": "mutex|rwlock|synchronized|semaphore|other", "locations": ["file:line"]}], "edges": [{"from": "lock_id", "to": "lock_id", "code_path": "function_name", "file": "string", "line_range": "start-end"}] }, "violations": [ { "severity": "CRITICAL|HIGH|MEDIUM|LOW", "cycle": ["lock_id_a", "lock_id_b", "..."], "conflicting_paths": [ { "path_description": "string describing the code path", "lock_order": ["lock_id_1", "lock_id_2"], "entry_points": ["function_name"], "file_locations": ["file:line"] } ], "deadlock_scenario": "string describing a concrete interleaving that triggers deadlock", "reproduction_conditions": "string describing thread count, timing, and state needed to reproduce" } ], "analysis_confidence": "HIGH|MEDIUM|LOW", "limitations": ["string describing analysis gaps or assumptions"] }

CONSTRAINTS

[CONSTRAINTS]

EXAMPLES

[EXAMPLES]

RISK LEVEL

[RISK_LEVEL]

If [RISK_LEVEL] is HIGH or CRITICAL, flag the output for human review before any automated action is taken.

After pasting this template, replace the placeholders with real values. For [LANGUAGE], use the programming language name (e.g., Java, Go, C++). For [CODE_BLOCK], include the complete functions or methods that acquire locks—partial snippets will produce unreliable results. For [CONTEXT], describe any project-specific locking conventions, known lock ordering rules, or lock wrappers that the model should account for. Use [CONSTRAINTS] to add any additional rules, such as ignoring test code or focusing only on production paths. Use [EXAMPLES] to provide a few-shot demonstration of correct analysis for your codebase. Set [RISK_LEVEL] to HIGH if the code runs in production with real concurrency, or LOW for offline analysis. Always route CRITICAL and HIGH severity findings to a human reviewer before taking automated action based on the output.

Integrating this prompt into an application requires treating it as a deterministic analysis step with strict input contracts and output validation, not as a conversational assistant. The prompt expects a structured codebase context—typically a set of files, a diff, or a function-level lock acquisition trace—and produces a lock graph and violation report. Before calling the model, the application must assemble the [CODE_CONTEXT] by extracting relevant synchronization primitives (e.g., mutex.Lock(), synchronized blocks, ReentrantLock) and their call sites. This extraction should be language-aware: a Go parser can identify sync.Mutex usage, while a Java parser must handle both intrinsic locks and java.util.concurrent locks. The harness should also inject a [LANGUAGE] parameter to activate language-specific lock semantics in the prompt.

After receiving the model output, the harness must validate the structure before surfacing findings. Parse the response against the expected [OUTPUT_SCHEMA]—a JSON object containing lock_graph (nodes and directed edges representing acquisition order) and violations (an array of cycles or ordering inconsistencies). Reject any response where the graph is malformed, edges reference undefined locks, or violation paths cannot be traced through the reported graph. For high-risk code paths (e.g., payment processing, database transaction boundaries), route violations to a human review queue rather than auto-commenting on a PR. Log every invocation with the commit SHA, the prompt version, the raw model output, and the validation result. This audit trail is essential when a deadlock surfaces in production and the team needs to understand why the pre-merge check did not catch it.

Model choice matters here. Use a model with strong code reasoning capabilities and a large context window—lock ordering analysis often requires tracing acquisition sequences across multiple files and call chains. If the codebase is large, pre-filter the [CODE_CONTEXT] to only include functions that acquire more than one lock or that call into lock-acquiring helpers. Avoid sending entire repositories; instead, use a static analysis pre-pass to identify candidate functions and build a focused context. For CI/CD integration, set a timeout of 30–60 seconds and implement a single retry on validation failure with a slightly modified prompt that includes the validation error message. If the retry also fails, surface the raw output and the validation error to the developer rather than silently dropping the finding. Never auto-merge a PR that has an unvalidated or failed lock ordering analysis.