Multi-threading Alternative

This situation comes about in a number of paradigms, including typical GUI based applications. For GUI's, one usually posts a message for the main UI thread to act upon.

The main thread in Unity is that which calls the various Update or FixedUpdate functions, so you can work this as simply as setting a bool (or some other state value) indicating the thread has requested a function to be called in the next Update or FixedUpdate of some appropriate object. Then, of course, that Update must read that bool, and call the function which performs DynamicGI.UpdateEnvironment, and resetting the bool.

You'll need to consider declaring that bool volatile, though quite often you won't really notice why that is important. I'll leave you to search the keyword to dive into the general topic of threading if it is unfamiliar.

Of course, this is all too simple if there are many such functions to call. An alternative, more generalized approach might be to create a class representing a delegate and parameters, possibly using generics if required. In this way threads could post such an object to a queue owned by an appropriate object. The queue represents a list of functions to be called on the main thread, probably in the next update.

Such a queue would require the kind of protections typical of threaded programming, as it will be accessed by competing threads. The design is beyond the scope of a post, but the basic idea is to use an array, likely constructed as a circular queue, or some kind of deque container, to receive requests from various threads. The Update function would then consume this container, performing each function in the list, leaving it empty.

There is a class created by pdwitte (search for UnityMainThreadDispatcher) that provides a service for this kind of situation.