Sharing state with an audio thread

[nebularnoise]

Hi !

I'm wondering whether immer would be a good fit for storing an audio application state.
My two hopes are:

1. it may make sharing the state across threads safer and more correct
2. implementing the memento pattern could be memory-effective, if leveraging structural sharing

But I have some concerns and questions.

Let's consider this:

immer::atom<state_t> global_state; // 'owned' and mutated by the main thread

void audio_callback(/* args */){
    const immer::box<state_t> state = global_state.load();

    /* do stuff */
} // <-- `state` goes out of scope here

It is my understanding that if by any chance the global state changed, and the audio thread ends up having the last reference to the underlying immer::box, the box will be deleted when state goes out of scope, which might block the audio thread.

Option 1: defer destruction

One naive fix I can see would be to defer the destruction of the box, with some kind of lockfree hand-written garbage collection, e.g.:

immer::atom<state_t> global_state; // 'owned' and mutated by the main thread
lockfree_queue<state_t>> gc_queue;

void audio_callback(/* args */){
    immer::box<state_t> state = global_state.load();

    /* do stuff */

    gc_queue.emplace(std::move(state));
}

void gc_callback()
{
    while(!gc_queue.empty()) gc_queue.pop();
}

Option 2: restrictions on the type

Another (less flexible way) would be to have the audio callback get the state by value, but that means we have to be sure no alloc/dealloc occur.

// guarantees no alloc/dealloc
static_assert(std::is_trivially_copy_constructible_v<state_t>);
static_assert(std::is_trivially_destructible_v<state_t>);

immer::atom<state_t> global_state; // 'owned' and mutated by the main thread

void audio_callback(/* args */){
    const state_t state = static_cast<state_t>(global_state);
}

It could work, but then I guess structural sharing within state_t is out the window...

---

Am I missing something? Are there memory policies that already do that sort of stuff ?

[arximboldi]

Good question and very detailed eye ;)

Option 1 is what I use in my code. You can wrap the pattern with some utilities to make it safe and easy for the user. It works well in practice and I never needed anything else.

Memory policies sadly can't be used for this purpose the way they're currently designed. I could envision API changes that would allow it (basically allowing the implementation of option 1 under the hood), but as I just mentioned, the workaround was good enough for me.

[nebularnoise]

Thanks a lot for your answer!

On the topic of implementing the memento pattern, do you have any recommendations? Are there any idioms of the library that could help?

[nebularnoise]

@arximboldi 'Discussions' are not enabled on the lager repo.
Is it ok to bother you with more questions about lager in an issue? 😅

[arximboldi]

I'll enable those

[arximboldi]

Does it work now?

[nebularnoise]

Yes, thank you!
I'll refine my draft a bit, and hit you up there 😄

[nebularnoise]

For cross-reference, here's a link to the discussion on the lager repo
arximboldi/lager#219