Difference between revisions of "AI War 2:Threading Model"
(Created page with "This is from a discussion with Chris about how threads work in AIW2. It's almost certainly irrelevant for anyone who isn't a dev or an extremely advanced modder. Here are the...") |
|||
| Line 4: | Line 4: | ||
1. MainThread. This is where a VERY small amount of sim happens. Mostly this is user input. GameCommands are NOT processed here. | 1. MainThread. This is where a VERY small amount of sim happens. Mostly this is user input. GameCommands are NOT processed here. | ||
| + | |||
2. ExeutionContext. I think this is sometimes called SimBG. This is the main sim loop, essentially, and it spawns all the short term threads. After they are done, it does some more work to integrate their data back into the main game. This is also where GameCommands get executed. | 2. ExeutionContext. I think this is sometimes called SimBG. This is the main sim loop, essentially, and it spawns all the short term threads. After they are done, it does some more work to integrate their data back into the main game. This is also where GameCommands get executed. | ||
| + | |||
3. ShortTermProcessing. There are a bunch of these. These are technically also part of the sim, and so I refer to them as "sim background threads," but they all run independently of one another before the ExecutionContext brings things back together. | 3. ShortTermProcessing. There are a bunch of these. These are technically also part of the sim, and so I refer to them as "sim background threads," but they all run independently of one another before the ExecutionContext brings things back together. | ||
| + | |||
4. LongTeamContinuous. There are like 5 of these. They run only on the host, and don't wait for the sim or have any direct impact on the sim. These do things like stack and unstack things, target planning, and so forth. Every so often they dump GameCommands into the main thread, which later sends them through the network and the executioncontext thread parses them. Even on single player, it sends it through loopback network and serializes and deserializes the commands, FYI. Keith and I did that to verify performance for multiplayer, since serialization is one of the slowest things. | 4. LongTeamContinuous. There are like 5 of these. They run only on the host, and don't wait for the sim or have any direct impact on the sim. These do things like stack and unstack things, target planning, and so forth. Every so often they dump GameCommands into the main thread, which later sends them through the network and the executioncontext thread parses them. Even on single player, it sends it through loopback network and serializes and deserializes the commands, FYI. Keith and I did that to verify performance for multiplayer, since serialization is one of the slowest things. | ||
| + | |||
5. LongTermIntermittent. There is one of these per faction TYPE. You're well familiar with these, as they execute the faction logic. However, some of the faction logic is executed on the "main" thread, which actually is the executionContext thread, so in that sense it considers the ExecutionContext to be the "main" thread. This disparity is largely because at one time it WAS the main thread, before we shifted it to have ExecutionContext in between. | 5. LongTermIntermittent. There is one of these per faction TYPE. You're well familiar with these, as they execute the faction logic. However, some of the faction logic is executed on the "main" thread, which actually is the executionContext thread, so in that sense it considers the ExecutionContext to be the "main" thread. This disparity is largely because at one time it WAS the main thread, before we shifted it to have ExecutionContext in between. | ||
| + | |||
--- | --- | ||
In general the naming can get slightly confusing because the model grew at one point. | In general the naming can get slightly confusing because the model grew at one point. | ||
Revision as of 18:34, 25 January 2020
This is from a discussion with Chris about how threads work in AIW2. It's almost certainly irrelevant for anyone who isn't a dev or an extremely advanced modder.
Here are the types of Threads in the game.
1. MainThread. This is where a VERY small amount of sim happens. Mostly this is user input. GameCommands are NOT processed here.
2. ExeutionContext. I think this is sometimes called SimBG. This is the main sim loop, essentially, and it spawns all the short term threads. After they are done, it does some more work to integrate their data back into the main game. This is also where GameCommands get executed.
3. ShortTermProcessing. There are a bunch of these. These are technically also part of the sim, and so I refer to them as "sim background threads," but they all run independently of one another before the ExecutionContext brings things back together.
4. LongTeamContinuous. There are like 5 of these. They run only on the host, and don't wait for the sim or have any direct impact on the sim. These do things like stack and unstack things, target planning, and so forth. Every so often they dump GameCommands into the main thread, which later sends them through the network and the executioncontext thread parses them. Even on single player, it sends it through loopback network and serializes and deserializes the commands, FYI. Keith and I did that to verify performance for multiplayer, since serialization is one of the slowest things.
5. LongTermIntermittent. There is one of these per faction TYPE. You're well familiar with these, as they execute the faction logic. However, some of the faction logic is executed on the "main" thread, which actually is the executionContext thread, so in that sense it considers the ExecutionContext to be the "main" thread. This disparity is largely because at one time it WAS the main thread, before we shifted it to have ExecutionContext in between.
--- In general the naming can get slightly confusing because the model grew at one point.
