An ISR enqueues bytes into a ring-buffer queue and the main loop dequeues them. Do you need a lock?

For the classic single-producer / single-consumer case, one writer (the ISR) that only ever advances head, one reader (the main loop) that only ever advances tail, you can make it lock-free, no critical section needed, if you're careful. The key is that each index has exactly one writer: the producer owns head, the consumer owns tail, and each side only reads the other's index. As long as index reads/writes are atomic (a single aligned word on the MCU, which a volatile uint32_t index is on a 32-bit core) and you publish the data before advancing the index the other side keys off, each observer sees a consistent view: the consumer never reads a slot until head has moved past it, and the producer never overwrites a slot until tail has freed it. That last point matters, memory ordering: on a core with a weak memory model or an aggressive compiler you need a barrier (or C11 atomics with acquire/release, or at minimum volatile plus a DMB) so the data write isn't reordered after the index update. The moment you have multiple producers or multiple consumers, the single-writer-per-index invariant breaks and you do need a lock (or disabling interrupts around the shared index). So: SPSC ring buffer, no lock but mind the barrier; anything else, protect it.