AudioParam: Use Acquire/Release ordering for handover in atomics

[uklotzde]

I consider this as the canonical ordering for passing of values in atomics to achieve a handover like a batton.

Unfortunately the spec explicitly allows write access to the current value slot by anyone, not only the processor.

If this applies to more use cases then the load and store orderings should be defined as constants and documented.

Thoughts?

[github-actions]

Benchmark result:


bench_ctor
  Instructions:             5134562 (No change)
  L1 Accesses:              7700319 (No change)
  L2 Accesses:                54114 (No change)
  RAM Accesses:               61576 (No change)
  Estimated Cycles:        10126049 (No change)

bench_sine
  Instructions:            78660295 (-0.009536%)
  L1 Accesses:            115603736 (-0.012977%)
  L2 Accesses:               278198 (No change)
  RAM Accesses:               62663 (No change)
  Estimated Cycles:       119187931 (-0.012587%)

bench_sine_gain
  Instructions:            83402751 (-0.013489%)
  L1 Accesses:            122761673 (-0.018328%)
  L2 Accesses:               318461 (No change)
  RAM Accesses:               62819 (No change)
  Estimated Cycles:       126552643 (-0.017779%)

bench_sine_gain_delay
  Instructions:           157500406 (-0.009525%)
  L1 Accesses:            223984558 (-0.013395%)
  L2 Accesses:               739079 (No change)
  RAM Accesses:               64504 (No change)
  Estimated Cycles:       229937593 (-0.013048%)

bench_buffer_src
  Instructions:            18563000 (-0.040548%)
  L1 Accesses:             26897272 (-0.055867%)
  L2 Accesses:                95270 (No change)
  RAM Accesses:               96102 (-0.001041%)
  Estimated Cycles:        30737192 (-0.049005%)

bench_buffer_src_delay
  Instructions:            91600259 (-0.012270%)
  L1 Accesses:            126739382 (-0.017744%)
  L2 Accesses:               215833 (No change)
  RAM Accesses:               96295 (No change)
  Estimated Cycles:       131188872 (-0.017143%)

bench_buffer_src_iir
  Instructions:            42547015 (-0.017629%)
  L1 Accesses:             61834100 (-0.024256%)
  L2 Accesses:               106615 (No change)
  RAM Accesses:               96197 (-0.001040%)
  Estimated Cycles:        65734070 (-0.022870%)

bench_buffer_src_biquad
  Instructions:            38968746 (-0.057672%)
  L1 Accesses:             54892175 (-0.081895%)
  L2 Accesses:               157160 (No change)
  RAM Accesses:               96311 (+0.002077%)
  Estimated Cycles:        59048860 (-0.076016%)

bench_stereo_positional
  Instructions:            46238806 (-0.137699%)
  L1 Accesses:             68500710 (-0.185810%)
  L2 Accesses:               722316 (No change)
  RAM Accesses:               96481 (+0.002073%)
  Estimated Cycles:        75489125 (-0.168545%)

bench_stereo_panning_automation
  Instructions:            32651637 (-0.034476%)
  L1 Accesses:             48672643 (-0.046235%)
  L2 Accesses:               159147 (No change)
  RAM Accesses:               96224 (+0.001039%)
  Estimated Cycles:        52836218 (-0.042527%)

bench_analyser_node
  Instructions:            39108236 (-0.019271%)
  L1 Accesses:             54839024 (-0.027424%)
  L2 Accesses:               196331 (No change)
  RAM Accesses:               96794 (No change)
  Estimated Cycles:        59208469 (-0.025400%)

[orottier]

I'm no expert on this so my stance is always:

• Relaxed when the threads don't really interact but just need to share some info
• SeqCst otherwise

Your reasoning sounds sensible and will be more performant, so I am all for it.

In the repo you will probably find the following other atomics usage:

• Relaxed for sharing render thread state (number of frames processed, etc). I think this is fine.
• SeqCst for passing audio node configs. This we will refactor anyway in Prevent out-of-order arrival of audio node settings #297

[orottier]

By the way, thanks again for your contribution. Your expertise is much appreciated!