Link session state modifications should only happen on the audio thread to achieve sample-accurate timing

Link provides two session state capture/commit function pairs: one safe for audio threads (realtime-safe, non-blocking), and one for application threads (may block, not realtime-safe). The recommended architecture for apps with a custom audio callback is to modify session state exclusively from the audio thread. Modifications from the application thread are processed asynchronously, so the audio thread may see the old state for an indeterminate number of samples after the change — making sample-accurate scheduling impossible. Worse, if an app thread commits state and then sets an atomic flag, the audio thread will almost certainly observe the flag before the new state, creating a race condition. Modifications from the audio thread, by contrast, can be specified to take effect at exact buffer boundaries or sample positions.

Examples

A user moves a tempo slider in the UI: the UI thread sends the new tempo value via a lock-free queue to the audio thread, which reads it during the next audio callback and commits the Link session state change. This ensures the tempo change takes effect at a precise audio sample.

Assessment

Why is it problematic to commit Link session state changes from an application thread when the app also uses Link from an audio thread? Describe the lock-free queue pattern that avoids this problem.