Introduction
This page describes synchronization issues that arise when accessing data from audio process thread and UI thread. Problem exists because audio processing is often high priority task and thus it not good idea to sleep (memory allocation, mutex lock) in audio process thread and because same data is accessed both from the audio processing thread and UI thread.
Here you will find some hints for two scenarios, realtime processing with high priority audio processing thread and offline audio processing (rendering). The two scenarios are somewhat controversal, but both modes of operation may be required in same application.
Realtime mode
In this mode audio processing is made in high priority thread. Speaking in Linux audio therms, JACK calls application process callback from realtime (SCHED_FIFO) thread. User interface is managed using normal thread, often the main thread of the system process.
Optimistic approach
This approach assumes that both threads are running on same processor always. This automagically happens on uniprocessor systems. On SMP systems, it can be forced using by setting threads affinity.
The audio processing thread running in such environment cannot be rescheduled to UI thread while running (during audio chunk process cycle). Thus all modifications made by audio processing thread are always atomic.
Pessimistic approach
We fall here if assumptions made by optimistic approach are not met. This means SMP systems with no thead affinity setup.
Something based on CAS atomic instruction should be used. Maybe "Lock-Free Techniques for Concurrent Access to Shared Objects." by Dominique Fober, Yann Orlarey, and Stephane Letz is good staring point.
Not time critical UI <-> audio thread data transfer
Since such data transfer is not time critical, audio thread can do "trylock" and skip transfer if lock is currently owned by the UI thread.
Offline/Render mode
In this mode audio processing is done as fast as possible and sleeping is allowed while processing audio. In this mode using conventional user-mode sleeping synchronization objects like mutexes is most natural way of handling synchronization. However in most cases, because audio is being rendered, protected data access of UI thread can be easily avoided.