Fix thread safety in fast_tanh toggle

[Ray0907]

---

Summary

• Fix thread safety issue in fast_tanh toggle by using std::atomic instead of modifying shared state
• Remove mutable global _activations map modification that could cause data races

Test plan

• Verify fast_tanh enable/disable works correctly in single-threaded context
• Test concurrent access from multiple threads toggling fast_tanh
• Confirm no performance regression with atomic load in hot path

---

[sdatkinson]

Thanks for the PR!

If you can check to make sure that this doesn't clash with the real-time safety of any of the nets, then this seems ok.

Also, some testing to cement the intent of the change would be appreciated.

[sdatkinson]

Does this change make the WaveNet's getting of the sigmoid activation for its gating activation no longer real-time safe?

NeuralAmpModelerCore/NAM/wavenet.cpp

Line 56 in 6ea03b1

activations::Activation::get_activation("Sigmoid")->apply(this->_z.block(channels, i, channels, 1));

[Ray0907]

Thanks for the review!

Real-time safety:

For non-"Tanh" lookups like WaveNet's "Sigmoid":

  if (name == "Tanh" && using_fast_tanh.load(...))
  //  "Sigmoid" != "Tanh" → short-circuits, atomic load never executed

It just hits the string comparison (false), then goes straight to find() - same as before, actually one fewer map lookup since we reuse the iterator now.

For "Tanh" lookups, the atomic load is lock-free with memory_order_relaxed - compiles down to a plain memory read on x86/ARM.

One thing I did consider: _activations.at("Fasttanh") technically can throw, though "Fasttanh" is guaranteed to exist. If you'd prefer, I can cache the pointer or use find() instead to be more defensive.

Tests:

Happy to add tests - what would you like to see? Unit tests for toggle behavior, multi-threaded stress tests, or both?