Some thoughts on the thread task

When a thread needs to access a piece of code or data, a lock is used to make sure that it does not have access to the code or data at the same time.

Thread B is accessible only when thread A has complete access to the code (just the code, the data is the same). Thread B is blocked when thread B accesses it while thread A is accessing it. Too many blockages and locks can make the efficiency drop.

Think about it, what does a thread a access to a piece of code mean?

My understanding is that this code needs to be executed at the present time in the entire system state.

Do I have to ask this code to execute immediately (relative to this thread)? It is entirely possible to make a task of executing this code and throw it into a specific thread C. Thread C loops through the queue to see if there is a task that needs to be performed, and when it sees that a task sent by thread A executes before it calls back to thread A, the callback can also take the thread queue, which sends the result to the queue of thread A. This allows each thread to collaborate only with its own message queue, greatly reducing the coupling.

This pattern also has a lot of problems, such as thread A needs to know immediately the execution result of this code, and then the following execution logic depends on this result.

But personally think this multi-threaded design is not good enough, there can always be a way to avoid this. Step back, if there is a situation where thread a needs to get execution results immediately, it can also be handled. Thread A sets this task to a high priority, and then constantly loops to determine if thread C is performing this task. If thread c is performing a time-consuming task at this time, you can even have thread C suspend execution of the current task before executing the task of thread A. This is rarely the case, mainly in some real-time systems.

In our game, there are mainly two threads. The logical thread is responsible for executing the relevant script logic and generating rendering data, and the rendering thread is responsible for rendering and OpenGL interface calls. Both of these are loop threads.

When a GL texture needs to be generated, the logical thread obtains the relevant image data and assigns a task to the render thread. The render thread loops through the message queue, discovers that the task that generated the texture is executed, and then puts the result in the message queue of the logical thread.

When a set of objects needs to be rendered, logical threads also use related data to generate a task to be placed on the render thread. The render thread can also define a priority, deciding whether to render first or as a texture.

When the rendering thread is busy and the logical thread is idle, some calculations can be put into logical threads, after all, the player's perceived frame rate depends on the minimum value.

In short, this Message Queuing approach reduces coupling and increases flexibility and robustness.

By abstracting the concept of threading into a higher-level task, thread-to-code execution rises to the point where a thread needs to execute a task at once, looking at a higher level of the problem, and discovering a lot more excellent designs.

Some thoughts on the thread task