Besides queues, what inter-task communication primitives does an RTOS offer, and when would you use them?

Queues are the general-purpose workhorse for passing data, but there are lighter and more specialized options. Task notifications are a fast, low-RAM mechanism that signals a specific task directly (and can carry a single 32-bit value or act as a lightweight binary/counting semaphore); they're significantly cheaper and faster than a queue or semaphore and ideal when there's a single notifier targeting one task and you don't need to buffer multiple items, for example an ISR waking one dedicated task. Stream buffers and message buffers handle byte streams and variable-length messages respectively, optimized for a single writer and single reader, well suited to funneling UART or sensor byte data to a processing task. Event groups hold a set of bits that tasks can set and wait on, letting a task block until several independent conditions are met ("wait for all of A, B, and C" or "any of them"), which a single queue or semaphore can't express cleanly, useful for synchronizing on multiple events. Mutexes and semaphores (previous lesson) cover mutual exclusion and event signaling. The selection logic: queue for general data passing and buffering; task notification for the fastest single-target signal or simple value handoff; stream/message buffer for byte/message streams with one reader; event group for waiting on combinations of flags; mutex for protecting a shared resource. Picking the lightest primitive that fits reduces RAM and latency, which matters on constrained devices.