[spacechild1]

Nice article! Yes, using spinlocks in normal userspace applications is not recommended.

One area where I found spinlocks to be useful is in multithreaded audio applications. Audio threads are not supposed to be preempted by other user space threads because otherwise they may not complete in time, leading to audio glitches. The threads have a very high priority (or have a special scheduling policy) and may be pinned to different CPU cores.

For example, multiple audio threads might read from the same sample buffer, whose content is occasionally modified. In that case, you could use a reader-writer-spinlock where multiple readers would be able to progress in parallel without blocking each other. Only a writer would block other threads.

What would be the potential problems in that scenario?

[Lectem]

I've heard of issues on Arm devices with properly isolated cores (only one thread allowed, interrupts disabled) because the would interact with other threads using such a spinlock, threads which were not themselves isolated. The team replaced it all with a futex and it ended up working better in the end. Sadly this happened while I was under another project so I don't have the details, but this can be problematic in audio too. To avoid the delay of waking up thread you can actually wake them a tiny bit early and then spin (not on a lock), since you know work is incoming.

[spacechild1]

For task queues we would use a lockfree queue, wake up the threads once at the beginning of the audio callback and then spin while waiting for tasks, just as you described.

My example above was rather about the DSP graphs themselves that are computed in parallel. These require to access to shared resources like audio buffers, but under no circumstance should they give up their timeslice and yield back to the scheduler. That's why we're using reader-writer spinlocks to synchronize access to these resources. I really don't see any other practical alternative... Any ideas?

[Lectem]

I suppose you need to be able to read data from the buffers to know what parts of the graph to cull? Is computing the graph really long or the graph needs update mid execution? If you really have nothing else to do on those threads/cores, spinning might actually be the solution(considering a high sampling rate). I'd still fallback to the OS after a certain amount of time, as it would mean you failed to meet the deadline anyway. I would also reduce as much as possible the need for writes to synchronized resources where possible, so that you can just read values knowing no writes can happen during your multiple reads.

[m-schuetz]

Recently implemented a fixed-size memory pool with spinlocks and now I'm wondering - how would one implement them without a spinlock?

Edit: Maybe I'm confusing terminology. What I'm doing is looping until other threads returned memory, but I'm also doing a short sleep during each loop iteration.

[Lectem]

That's a spin loop ;)

[m-schuetz]

I see, thanks.