Make widelands multithreaded

Registered by Victor Pelt

There are several places widelands could take advantage of being a multithreaded application (and thus reap benefits on multicore cpu's). This includes having the AI and GUI being a separate thread from the game logic

Blueprint information

Not started
Victor Pelt
Needs approval
Victor Pelt
Series goal:
Milestone target:

Related branches



So far i have identified the following (possible) threads

* Main (start) menu
starts - Game Logic, GUI, Sound

* Game Logic/ including network game simulation code
interfaces with AI player, GUI

* AI player
interfaces with Game Logic

interfaces with Game Logic, Sound

* Sound
interfaces with Game Logic, GUI

private/chat messages. i'm tempted to separate those out from the game logic thread since it shouldn't matter if they get delivered (on time) or dropped

Tasks include
- clean up interface AI uses to communicate with game logic
- clean up interface GUI uses to communicate with game logic
- make game logic interface thread safe


Alternatively, a first approach could be the implementation of a simple queue of commands.
Commands get executed by a pool of threads and answers sent back in a queue
of commands that get executed in the main thread.
This could be used at load time specially when loading animations where I expect the bottleneck
is reading from the disk: the loading (from files) is executed in a thread and the registration is
executed in the main thread. Loading is finished when the queue is empty (or using a difference between
expected load and effectively done).
The advantage of such an approach is that you don't need to make the code thread safe from the start,
but simply split the execution into a threadified part and a common part.


I don not agree with your splitting. There should be as less threads as possible. Code across different threads is much harder to debug and thread may introduce many ugly bugs (especially deadlocks). The code should be split into different threads a) where it is really necessary (UI for faster response to action) and b) where an interface(/split) is already in the code (logic, ai).

So I propose the following layout:

* UI
  The ui should always respond fast to user actions.

* game logic

* AI

* network code
  to avoid blocking the UI

I think the game controller should be placed in the UI. The game logic the sees nothing about multiplayer/singleplay/network but only game logic. Much more important than implementing the actual threading is how will the communication be done. This should be drafted first and discussed with other developers.

I see mainly two possibilities:
* shared memory:
  UI, game logic and AI share the same copy of the internal game structures (map, object states). This is the easiest way to do it. But it also has big disadvantages: The threads are not independent and most of the code will be serialized due to the map being locked by one thread. And it will not be possible to run the part on different hosts.

* message queue, socket, some sort of passing only data between the threads
  All threads that need get get an initial copy of objects they are interested in. Then these are updated by change notifications. This is much harder to implement, but in my opinion a much better way. There were already discussions about making game state observable. These should be continued with threading in mind.



Work Items

This blueprint contains Public information 
Everyone can see this information.