Why use a queue instead of a shared global protected by a mutex?

Because the queue is the synchronization, which eliminates a whole class of bugs and decouples the tasks. With a shared global and a mutex, you have to take the lock on every access, hold it only briefly, release it on every code path, and reason about who's touching the data when, and any slip (a forgotten unlock, a too-long critical section, an unguarded access) reintroduces races or priority inversion. A queue's send and receive are atomic and internally synchronized, so there's no separate lock to manage and no race window. It also decouples timing: the queue buffers items, so a bursty producer and a slower consumer don't have to run in lockstep, the depth absorbs bursts and the consumer blocks (using no CPU) when empty rather than polling. And it conveys ownership cleanly: data is either copied by value (the receiver gets its own copy) or handed off by pointer with an explicit ownership rule, avoiding the "is anyone else looking at this global right now?" ambiguity. The guiding principle is "communicate to pass data rather than share memory", message passing through queues sidesteps shared-state races by design. You'd still use a mutex for genuinely shared resources that can't be modeled as a message (a bus, a peripheral), but for moving data between tasks a queue is usually cleaner and safer.