Add async threads #2219

flaviojs · 2018-07-17T05:17:11Z

This PR introduces a way to split loading/processing stuff and GUI stuff.

An example split is done in the WaitingForGameStart state of the human client.
The data is loaded in an async thread. When done it adds the UI updates to the GUI work queue, which is executed before the next frame is rendered.
As a consequence, when you continue a game from the intro menu, instead of being frozen you will be able to move the mouse during the initial load (before the PlayingTurn state).

Topic: http://www.freeorion.org/forum/viewtopic.php?f=9&t=11009

The code is stored in a thread-safe work queue. It is executed before the next frame is rendered.

Dilvish-fo · 2018-07-17T15:01:29Z

Particularly in light of that last commit that was just added, it seems like this should probably be labeled as "testing requested" and/or "work in progress"

flaviojs · 2018-07-17T16:52:23Z

This should be "work in progress" until someone decides what to do with unhandled exceptions in async threads, which is not my decision to make. For now I'm just adding a line to ErrorLogger().

As for the last commit. I added is_loading code when I was reverting changes to trace messages before pushing this PR. I though I had tested it at the time but it seems like I only tried compiling... won't happen again, sorry. :(

geoffthemedio · 2018-07-18T17:03:27Z

client/human/HumanClientFSM.h

+    //! Update UI in the GUI thread.
+    void ProcessUI(bool is_new_game, const SaveGameUIData& ui_data);
+
+    volatile bool is_loading = false;  //!< true from GameStart to DoneLoading


Are you sure you know what you're doing with volatile?

http://cxx.isvolatileusefulwiththreads.com

Atomic access is not needed here, so volatile is enough. Do you prefer std::atomic?

It is written in one thread and read in another, but the access is sequential (not concurrent). I just need to make sure it is not reading a cached value, therefore volatile is enough.

If your answer is 'yes', that's fine.

geoffthemedio · 2018-07-18T17:04:21Z

client/human/HumanClientFSM.cpp

@@ -782,29 +783,61 @@ WaitingForGameStart::WaitingForGameStart(my_context ctx) :
 }

 WaitingForGameStart::~WaitingForGameStart()
-{ TraceLogger(FSM) << "(HumanClientFSM) ~WaitingForGameStart"; }
+{


{ to previous line

geoffthemedio · 2018-07-19T11:25:01Z

UI/ClientUI.cpp

@@ -1044,6 +1044,29 @@ std::vector<std::shared_ptr<GG::Texture>> ClientUI::GetPrefixedTextures(const bo
    return prefixed_textures_and_dist.first;
 }

+bool ClientUI::PushWork(std::function<void()> work)
+{


same adjustment to { in various other non-template places with a single line function name and parameters

geoffthemedio · 2018-07-19T11:26:44Z

UI/ClientUI.h

+    /** Add work for the GUI thread. */
+    bool PushWork(std::function<void()> work);
+
+    /** Get and remove work for the GUI thread. */


What does it mean to "remove work for the GUI thread" ?

geoffthemedio · 2018-07-19T11:29:46Z

client/human/HumanClientFSM.h

    boost::statechart::result react(const GameStart& msg);

    CLIENT_ACCESSOR
+
+    //! Load data in an asyc thread.


what data? explain what this does / how / why.
should these functions be private?

geoffthemedio · 2018-07-19T11:33:11Z

client/human/HumanClientFSM.h

@@ -36,6 +37,9 @@ struct TurnEnded : boost::statechart::event<TurnEnded> {};
 // Posted to advance the turn, including when auto-advancing the first turn
 struct AdvanceTurn : boost::statechart::event<AdvanceTurn> {};

+// Indicates that everything has been loaded.


what does "loaded" mean?

geoffthemedio · 2018-07-19T11:39:19Z

client/human/HumanClientFSM.cpp

@@ -815,6 +848,13 @@ boost::statechart::result WaitingForGameStart::react(const GameStart& msg) {
    GetGameRules().SetFromStrings(Client().GetGalaxySetupData().GetGameRules());

    bool is_new_game = !(loaded_game_data && ui_data_available);
+    Client().GetClientUI().PushWork(


not clear about what's going on / why. ProcessData is called within launch_async but then it calls the PushWork function... why in that order?

geoffthemedio · 2018-07-19T14:11:16Z

client/human/HumanClientFSM.cpp

@@ -826,7 +866,7 @@ boost::statechart::result WaitingForGameStart::react(const GameStart& msg) {

    Client().GetClientUI().GetPlayerListWnd()->Refresh();

-    return transit<PlayingTurn>();
+    context<HumanClientFSM>().process_event(DoneLoading());


why does this function generate the DoneLoading event and not the caller? It and ProcessData and ProcessUI don't seem to be used elsewhere.

flaviojs · 2018-07-19T21:12:13Z

@geoffthemedio
I guess an explanation on how this works is in order.

Currently the main thread is used as GUI thread and processing thread, causing visible freezes every time processing takes a bit longer than an instant (for me it drops to 0/1 FPS quite often).

In OpenGL, almost every interaction must happen in the thread that created the OpenGL context. It is possible to create additional contexts but that would only complicate things.

If I want to separate processing from the GUI thread, then the processing code must have some way to tell the GUI thread that it can execute the UI code that depends on the processed data.

In this approach the processing code can add work (arbitrary code as a std::function<void()>) to a queue.
ClientUI is used as a singleton and is accessible to all UI code of the human client, so it is a suitable place to hold the FIFO work queue for the GUI thread.
HumanClientApp::HandleSystemEvents is called by the GUI thread just before rendering a frame, so it is a suitable place to execute the work that was added to the queue.

In short, GUI work is arbitrary code to be executed before rendering a frame, and any thread can add GUI work. Some renaming might be needed to make it clearer, but I can't think of better names...

Now then, let's explain the split in WaitingForGameStart...

When the GameStart message is received, HumanClientApp::HandleSystemEvents will call HumanClientApp::HandleMessage, which calls m_fsm->process_event(GameStart(msg));, which in turn calls WaitingForGameStart::react(const GameStart& msg).

The code here modifies Universe-related data and then updates the UI.

What I did was split that into two functions, WaitingForGameStart::ProcessData and WaitingForGameStart::ProcessUI, and make the first one execute in an async thread.

This is the new sequence:

GUI thread executes WaitingForGameStart::react(const GameStart& msg) and launches an async
async thread executes WaitingForGameStart::ProcessData while the GUI thread continues executing normally (processing keyboard events, processing mouse events, processing network messages, and rendering frames)
async is done and tells the GUI thread to execute WaitingForGameStart::ProcessUI (by pushing work to the queue)
GUI thread pops work from the queue and executes WaitingForGameStart::ProcessUI (before rendering the frame)

WaitingForGameStart::ProcessUI is called from HumanClientApp::HandleSystemEvents so it can't transit state (FSM isn't being processed), and since the FSM is only processed when a network message arrives I can't just post a DoneLoading event either (would be processed when a network message arrives).

Ideally the FSM would run in it's own thread, allowing you to post events from anywhere, but that would require splitting all UI code from the react functions of the FSM and that is not what this PR is about.

Since WaitingForGameStart::ProcessUI is already executing in the thread that processes the FSM, it is sufficient to call process_event(DoneLoading()) on the FSM.

geoffthemedio · 2018-07-26T14:47:25Z

Too busy at the moment to go through all you wrote, but I particularly wanted any non-clears bits of that explained in the code with comments.

They are in a struct but they don't need to be public.

flaviojs · 2018-07-29T13:59:10Z

@geoffthemedio I tried to answer all your questions with comments in the code.

It would be nice if you guys documented the preferred code style.
The wiki says to try to match surrounding code, but in ClientUI there is a mixture of styles. (example: around PushWork/PopWork there are different function bracket styles; on a new line; next to the function declaration; open and close on the same line)

geoffthemedio · 2018-09-02T22:22:43Z

I've tested this now, in comparison with master, with a 650 star galaxy and about 10 AIs, medium or high on most settings. I don't see much difference... There's a less-than-half second pause for the mid-turn update, and a slightly longer pause for the main turn update, during which the UI seems to hang. Seems quite similar for both. Do you have a better test case or expect to see a more substantial difference with this pull request applied?

flaviojs · 2019-09-22T15:11:05Z

I'm not gonna be around to continue this so maybe it should be closed?

I hate seeing software freeze. From a UI perspective, not giving feedback is bad.
The aim of this was not to improve speed, but to allow the game to give feedback to the user, which is mouse movement in this case.

Vezzra · 2019-10-02T11:15:30Z

@geoffthemedio, so do I understand correctly, even if @flaviojs isn't going to work on this anymore, you want that to keep it open and continue working on it/wait for someone to pick it up?

flaviojs added 3 commits July 17, 2018 05:44

The GUI thread is able to execute additional code.

6769077

The code is stored in a thread-safe work queue. It is executed before the next frame is rendered.

WaitingForGameStart loads data asynchronously.

e0a4aab

Put is_loading in the right place and make it volatile.

06abae8

Vezzra added category:feature The Issue/PR describes or implements a new game feature. component:UI The Issue/PR deals with the game user interface, graphical or other. component:internal The Issue/PR deals with any project component that has no explicit `component` label. labels Jul 17, 2018

Vezzra added this to the post 0.4.8 milestone Jul 17, 2018

Dilvish-fo added the status:testing requested The Implementation can't be tested sufficiently by the developer and require support. label Jul 17, 2018

Dilvish-fo added the status:work in progress The PR contains some implementation but isn't ready for merging onto the main development branch. label Jul 17, 2018

geoffthemedio reviewed Jul 18, 2018

View reviewed changes

flaviojs added 2 commits July 19, 2018 10:56

Fix style.

6ba6c2c

Replace volatile with std::atomic.

556592a

geoffthemedio reviewed Jul 19, 2018

View reviewed changes

flaviojs mentioned this pull request Jul 25, 2018

Add EncyclopediaDetailPage. #2225

Closed

flaviojs added 3 commits July 29, 2018 14:27

Document the example split in more detail.

3174e24

Make ProcessData, ProcessUI and is_loading private.

022af1a

They are in a struct but they don't need to be public.

Update style as requested.

c6ac121

Vezzra removed this from the Next Release milestone Sep 22, 2019

geoffthemedio modified the milestones: Gateway to the Void, post release Sep 22, 2019

Vezzra removed this from the post release milestone Feb 9, 2020

geoffthemedio closed this May 16, 2020

Vezzra added this to the Gateway to the Void milestone May 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add async threads #2219

Add async threads #2219

flaviojs commented Jul 17, 2018

Dilvish-fo commented Jul 17, 2018

flaviojs commented Jul 17, 2018

geoffthemedio Jul 18, 2018

flaviojs Jul 19, 2018 •

edited

geoffthemedio Jul 19, 2018

geoffthemedio Jul 18, 2018

geoffthemedio Jul 19, 2018

geoffthemedio Jul 19, 2018

geoffthemedio Jul 19, 2018

geoffthemedio Jul 19, 2018

geoffthemedio Jul 19, 2018

geoffthemedio Jul 19, 2018

flaviojs commented Jul 19, 2018 •

edited

geoffthemedio commented Jul 26, 2018

flaviojs commented Jul 29, 2018

geoffthemedio commented Sep 2, 2018

flaviojs commented Sep 22, 2019

Vezzra commented Oct 2, 2019 •

edited

Add async threads #2219

Add async threads #2219

Conversation

flaviojs commented Jul 17, 2018

Dilvish-fo commented Jul 17, 2018

flaviojs commented Jul 17, 2018

Choose a reason for hiding this comment

flaviojs Jul 19, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flaviojs commented Jul 19, 2018 • edited

geoffthemedio commented Jul 26, 2018

flaviojs commented Jul 29, 2018

geoffthemedio commented Sep 2, 2018

flaviojs commented Sep 22, 2019

Vezzra commented Oct 2, 2019 • edited

flaviojs Jul 19, 2018 •

edited

flaviojs commented Jul 19, 2018 •

edited

Vezzra commented Oct 2, 2019 •

edited