Casey introduced the idea of a transient memory block that can be rebuilt when needed from the persistent memory. This means that the memory block can be reclaimed and rebuilt on demand for example when the user pauses and resumes the game. I really like that idea.

When the code was all single-threaded everything was nice and simple. However, now (I am at day 150) the transient block is also being accessed from threads (ground chunk composition).

What happens if the OS wants to reclaim the transient memory while it is still in use in the background? Does the game have a mechanism that inhibits the OS from removing the transient block while the threads are still using it? If not, how will this be managed in the future?

One way would be to let the OS signal the threads to stop and only reclaim the memory when they have exited, but that seems pretty complex. All transient-related background code would have to listen for a signal and implement some kind of early out.

This whole thing might be unproductive premature speculation but I am curious :-)

The OS never reclaims any blocks you don't tell it to.

Okay, I did not express myself clearly I see now. I am talking about whenever our platform code explicitly decides to free the transient memory for whatever reason. For example, we might want to free the transient memory if the user switches to another application without closing our game (like Alt+tabbing for example). Another example would be iOS' UIApplicationDelegate#applicationDidReceiveMemoryWarning. In these circumstances out platform layer could potentially decide to explicitly free the transient memory and then later rebuild it when the game is resumed.

The above is based on my understanding of Casey's idea about transient memory. That understanding might be wrong of course.

But assuming my understanding is fairly correct, how do we make sure that we don't free memory being actively used by background threads in these cases?

I hope this clarified my question.