What are the common bugs with locks in an RTOS?

Several recur. Lock leaks: a code path that takes a mutex and returns early (an error branch, an early return) without giving it leaves the resource locked forever, so the next taker blocks indefinitely, effectively a deadlock; the fix is disciplined pairing of take/give on every path (RAII in C++, careful single-exit or goto-cleanup patterns in C). Holding locks too long: a long critical section, or worse blocking on something slow while holding the mutex, stalls every other user and amplifies priority inversion and latency, you should do the minimum under the lock and never call a blocking API while holding it. Wrong primitive: using a non-inheriting semaphore to protect a resource reintroduces unbounded priority inversion, and treating a mutex as a signal breaks its ownership semantics. Taking a mutex in an ISR (illegal, ISRs can't block). Self-deadlock: a task taking a non-recursive mutex it already holds blocks on itself; if re-entrancy is genuinely needed, use a recursive mutex (and give it the same number of times). And multi-lock deadlock: acquiring two or more mutexes in inconsistent orders across tasks can deadlock (the next lesson), fixed by a global lock-ordering convention or timeouts on take. The throughline is that locks introduce a whole class of liveness bugs (deadlock, leaks, inversion) on top of the safety they provide, so they demand discipline: short critical sections, paired acquire/release on all paths, the right primitive, and consistent ordering.