Add Mutihtreading

[Klaus Halfmann]

As of RC19 Widelands uses a single Processor only. When you check top or other tools, Widelands is at about 100% for one core and alle the other cores are idle. As all moder CPUs (even a Raspi) have mutiple cores Widelands should support this. This could be done as follows.

* Fork off a "Rendering" Thread, cares for rendering only.
* Fork off one or multiple "AI threads"
* Fork off a "Sound" Thread.
* Fork off an "Autosave" Thread, this blocks the game flow a lot on big maps.
* Avoid a significate increase in memory usage.

The Wideland structures are _not_ Thread safe as of now and making them all
completly thread safe is a big task. To allow a simple transition there are
multiple ways migrate to a final solution:

a) Use a single "Update" Thread - and allow only this thread any modifications

* As Widelands already uses a kind of command queue this should be feasible.
* All read access must be blocked during the (atomic) writes.

b) Copy all need structures for some of the Thread.

* as the main Map is a huge structure this may increas the memory footprint and contradict the requirement above

c) Redesign major games structures for Mutithreading

* Well, this is a huge task of its own

As I am not that familiar with some of the Internas here,
I ask our "Architects team" ;-) for comments.

[SirVer (sirver)]

Widelands predates multicore architecture, therefore it was never designed with the idea of multithreading. I think it is very hard to design it into the core of the game, since we so strongly ingrain doing one thing at a time.

I also would suggest to not change this - never. The logic of Widelands is simple and a single core can handle a big game quite easily. There are obvious bottlenecks in the routing which could probably use a parallel approach locally - for example routing - but in general, I would always keep the core single threaded.

I think making AIs multithreaded is the obvious first step in distributing load and should be quite simple:

1) Introduce an API that let's AI observe the game and enqueue updates (through Player messages, i.e. the same way a network player needs to do it).
2) All updates happen at once at the end of a frame (same as for multiplayer right now).
3) Spin up a separate thread for each AI player.

I think this is closest to your a) suggestion, but more limited. It reduces the engine to a sort of server that processes time ordered player commands and guarantees immutability for a certain amount of time so that the view of each player is correct.

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/2056