# AudioProcessorValueTreeState raw value pointer thread-safety **URL:** \ **Category:** General JUCE discussion\ **Created:** [October 21, 2018, 12:39pm UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957 "2018-10-21T12:39:33Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![CrushedPixel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crushedpixel/32/8654_2.png) [@CrushedPixel](https://forum.juce.com/u/CrushedPixel)\ **Post date:** [October 21, 2018, 12:39pm UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957/1 "2018-10-21T12:39:34Z")
Are the pointers returned by `AudioProcessorValueTreeState::getRawParameterValue` implemented to be thread-safe? I know that it’s realtime-safe to access them from the Audio Thread, but is it thread-safe if I modify these values from the Message Thread using `AudioProcessorValueTreeState::getParameter().setValue()`? ---
**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\ **Post date:** [October 22, 2018, 9:53am UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957/2 "2018-10-22T09:53:03Z")
Technically, no; they’re not thread safe. However, unless you’re running on some very unusual hardware, there’s no need to panic. Loads more info here: > [@AudioParameter thread safety](https://forum.juce.com/t/audioparameter-thread-safety/21097): > > I am looking at the AudioParameterFloat and AudioParameterInt classes in JUCE and I fail to see how they are thread safe. It appears that setValue sets the value and the audio thread gets the value without any sort of fifo or thread safety despite in their base class AudioProcessorParameter it says that getValue and setValue should be “thread aware”. Is it safe to use these classes and set them on the UI thread and get them on the Processing thread as is done in the AudioPlugin Examples? ---
**Author:** ![CrushedPixel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crushedpixel/32/8654_2.png) [@CrushedPixel](https://forum.juce.com/u/CrushedPixel)\ **Post date:** [October 22, 2018, 11:30am UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957/3 "2018-10-22T11:30:29Z")
Hm. I’m kind of with @mayae on this issue, as I’ve spent the past week completely re-writing my plug-in’s internals to thread-safely and realtime-safely (that one was annoying) access and modify the internal data structure from both the Message and Audio Thread, only to find out that the other half of my plug-in (which uses the APVTS) doesn’t give a damn about it. Would it be too difficult to change the `ParameterAdapter::unnormalisedValue`'s type from `float` to `atomic`? If we’re going the “let’s assume we’re running on usual hardware” route, these should be realtime-safe (as in lock-free). If `atomic` is _not_ lock-free on some platform, it wouldn’t be realtime-safe anymore, but in that case not having it atomic would probably break thread-safety completely, so it’s better in any case. ---
**Author:** ![CrushedPixel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crushedpixel/32/8654_2.png) [@CrushedPixel](https://forum.juce.com/u/CrushedPixel)\ **Post date:** [October 22, 2018, 11:47am UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957/4 "2018-10-22T11:47:13Z")
I realize that this would change the interface of `getRawParameterValue` to return an `atomic *`, but for most use cases, client code wouldn’t even need to be updated, since `atomic` is implicitly convertible to `float` and exposes an assignment `operator=(float)` ---
**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\ **Post date:** [October 22, 2018, 1:12pm UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957/5 "2018-10-22T13:12:24Z")
Adding a thread safe way of accessing the raw parameter values is on our todo list. As Fabian said in the other thread, we’re not arguing against the use of atomics. > [@CrushedPixel](#): > > but for most use cases … only if you’re using `auto` or not storing the parameter value at all. There are a handful of similar breaking changes we want to make, which we’ll do sometime shortly after the next JUCE release. This gives people the maximum amount of time to adapt their code. ---
**Author:** ![CrushedPixel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crushedpixel/32/8654_2.png) [@CrushedPixel](https://forum.juce.com/u/CrushedPixel)\ **Post date:** [October 22, 2018, 1:13pm UTC](https://forum.juce.com/t/audioprocessorvaluetreestate-raw-value-pointer-thread-safety/29957/6 "2018-10-22T13:13:03Z")
Thanks, that’s great to hear. I really appreciate that you’re listening to your user base 🙂