Deadlock Prevention & Priority Inversion

  Task A holds Mutex_SPI; waits for Mutex_CAN
  Task B holds Mutex_CAN; waits for Mutex_SPI
  → Both blocked forever (neither can proceed)

  Four conditions for deadlock (Coffman conditions):
  1. Mutual exclusion: resources used exclusively (mutex)
  2. Hold and wait: task holds resource while waiting for another
  3. No preemption: resources cannot be forcibly taken
  4. Circular wait: T1 waits for T2's resource; T2 waits for T1's

  Prevention: break any one condition:
  ├── Lock ordering: always acquire mutexes in a fixed global order
  │   e.g., always: Mutex_SPI THEN Mutex_CAN (never reverse)
  ├── Try-lock with timeout: if cannot acquire in N ms, release all held + retry
  └── Avoid holding multiple mutexes simultaneously (use a single aggregated lock)

  Task Priority:  High(H) = 10  Medium(M) = 5  Low(L) = 1

  t=0:  Task L runs; acquires Mutex_Bus
  t=1:  Task H pre-empts L; tries to acquire Mutex_Bus → blocked (L holds it)
  t=2:  Task M pre-empts L (M > L); M runs indefinitely
  t=3:  Task H (highest priority!) starves because M blocks L from releasing Mutex_Bus
  → H has been indirectly "blocked" by M, which has lower priority

  This caused the 1997 Mars Pathfinder resets:
  High-priority bus management task starved by low-priority meteorology task
  Fix: enable priority inheritance on the mutex

  Priority Inheritance (FreeRTOS Mutex):
  When H blocks on a mutex held by L:
  → L's priority is temporarily raised to H's priority
  → M can no longer pre-empt L (L now has H's priority)
  → L runs to completion, releases mutex, reverts to priority 1
  → H unblocks and runs normally