Class InterproceduralDeadlockCheck

java.lang.Object
org.ek9lang.compiler.phase5.lockanalysis.InterproceduralDeadlockCheck
public final class InterproceduralDeadlockCheck extends Object
Phase C.3 of slice-2 deadlock detection — Phase 5 lock-order-cycle model.

Walks each paired (outer enter, MutexKey body) and consults the body's mayEnter for transitive inner enters. The verdict for each pair:

  • Same lock identity + SAME_THREAD → OK (reentrant on same thread).
  • Same lock identity + CROSS_THREAD → E08253 (immediate emit — cross-thread reentry isn't safe even though same-thread reentry is).
  • Different lock identity → record a precedence edge outer → inner in the workspace LockPrecedenceGraph. Do NOT emit yet — a single-direction nesting is safe; only a CYCLE forms an actual deadlock risk.

After all enter sites are visited, run Tarjan SCC on the precedence graph. For each non-trivial SCC (≥ 2 lock identities mutually reachable via nesting edges), emit E08252 at every participating edge's inner-enter location. The error message names both the inner and outer lock identities so users see the cycle they participate in.

Why cycles, not all nesting: a single function that does lockA.enter(outer { lockB.enter(inner) }) is safe if nothing else in the program does the reverse. The deadlock condition only exists when two acquisition orders contradict — that's the cycle. Strict "always reject nested-different" would over-flag legitimate single-direction nesting; this model matches the canonical lockdep (Linux kernel) approach and EK9_CONCURRENCY_MODEL.md §664.

  • Constructor Details

  • Method Details

    • check

      public void check()