# Lock-free shared\_ptrs?

**URL:** <https://forum.juce.com/t/lock-free-shared-ptrs/39240>\
**Category:** General JUCE discussion\
**Created:** [May 6, 2020, 10:00am UTC](https://forum.juce.com/t/lock-free-shared-ptrs/39240 "2020-05-06T10:00:04Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![dave96](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/dave96/32/8487_2.png) [@dave96](https://forum.juce.com/u/dave96)\
**Post date:** [May 6, 2020, 6:37pm UTC](https://forum.juce.com/t/lock-free-shared-ptrs/39240/6 "2020-05-06T18:37:19Z")

</div>

I think you’re over complicating it. What you really want is just a real-time spin lock around your `currentSound` and make sure you only ever call `tryLock` on the real-time thread. If this fails, it means your non-real-time thread is currently assigning a new sound and you’ll have to render without the sound.

@timur wrote about this in great detail recently with an almost identical use case: [https://timur.audio/using-locks-in-real-time-audio-processing-safely](https://timur.audio/using-locks-in-real-time-audio-processing-safely)

* * *

The only other thing I would say is to try and avoid getting in to this case in the first place.  
In general, if you can make your render graph rebuild when something like a sound file changes you never end up in this situation as you just have a root node to process that you can swap atomically.

---

_[View the full topic](https://forum.juce.com/t/lock-free-shared-ptrs/39240)._