FreeOrion

Forums for the FreeOrion project
It is currently Tue Jul 17, 2018 4:06 am

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Add a thread to Universe
PostPosted: Mon Jul 09, 2018 12:15 pm 
Offline
Space Krill

Joined: Sat Jul 07, 2018 7:24 pm
Posts: 9
Short version:

Add a permanent thread to Universe.
That thread will execute all std::function<void(void)> that are added to a FIFO queue (scheduled).

----

Long version:

The UI freezes were bothering me in single player games.
But I was really shocked when I tried being an observer in a multiplayer game with 6 AIs... the UI was frozen more than half of the time!!
It was so bad that I was only able to explore existing fleets and systems when the AIs started taking more than a minute to finish their turns.
In short, UI freezing became a much bigger issue for me. :x

In https://github.com/freeorion/freeorion/issues/2188 I learned that calculations were being done in the UI thread.
I can see that the current Universe isn't friendly to multi thread access.
Looking at the CMakeLists.txt you are targetting C++11, so you already have std::function, std::bind, and lambdas.

This proposal is a starting point to multi-threading, and consists of isolating Universe updates to a single thread (not the UI thread).
One way to do this is adding a thread to Universe, that would wait for work to be scheduled in a std::list<std::function<void(void)>> and execute it in FIFO order.

For single function calls scheduling with std::bind would be enough:
Code:
GetUniverse().Schedule(std::bind(&Function, argument));
or
GetUniverse().Schedule(std::bind(&Class::MemberFunction, pointer_to_class_instance, argument));

For more complex code it could schedule a lambda:
Code:
// do stuff in original thread
GetUniverse().Schedule([this, data] () {
  // do stuff in Universe thread (lambdas can only introduce variables in C++14)
  GetUniverse().UpdateSomething(data);
  this->m_atomic_var = GetUniverse().GetSomething();
  this->RequirePreRender();
});
// do stuff in original thread (probably before or during the lambda)


For reads, it might require a write lock but there are too many entry points, so I will think about it latter.
I'd like some feedback on this idea first. :)
What are your thoughts on this proposal?


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 1:20 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12231
Location: Munich
You would probably need to consider modifications the whole gamestate, not just the Universe and its contents.


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 8:21 pm 
Offline
Space Krill

Joined: Sat Jul 07, 2018 7:24 pm
Posts: 9
I thought Universe and the Managers in the universe folder were the game state, and that the rest of the code accessed and manipulates these.
Is there more?


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 9:42 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12231
Location: Munich
Empires. Possibly supply, though it's debatable as I think it's all derived from other state and not independently meaningful. Possibly diplomacy.


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 11:06 pm 
Offline
Space Krill

Joined: Sat Jul 07, 2018 7:24 pm
Posts: 9
Ok. It seems you're not against the idea of an asynchronous UI, so for now I'll give it a try and see it if it's feasible and appropriate.


Top
 Profile  
 
PostPosted: Tue Jul 10, 2018 7:04 pm 
Offline
Space Kraken

Joined: Sat Dec 10, 2011 5:46 am
Posts: 135
Will you consider option when your client asynchronously initiates scheduled process on server and then disconnects without stopping the game?

_________________
Gentoo Linux x64, gcc-7.3, boost-1.65.0
Ubuntu Server 18.04 x64, gcc-7.3, boost-1.65.1
Welcome to multiplayer server at freeorion-test.dedyn.io.Version 2018-07-13.9a06376 0.4.8 RC2
Donates are welcome: BTC:14XLekD9ifwqLtZX4iteepvbLQNYVG87zK


Top
 Profile  
 
PostPosted: Tue Jul 10, 2018 10:03 pm 
Offline
Space Krill

Joined: Sat Jul 07, 2018 7:24 pm
Posts: 9
I'm not sure what you mean by that, but if it's handled correctly now then it will probably be handled correctly with a Universe thread too.
(I intend to keep equivalent functionality)


Top
 Profile  
 
PostPosted: Wed Jul 11, 2018 6:41 pm 
Offline
Space Krill

Joined: Sat Jul 07, 2018 7:24 pm
Posts: 9
I see that changes would propagate all the way to the AI client and server.
However, freezing is essentially a GUI thing and they don't have a GUI, so a thread in Universe doesn't seem appropriate.

Next I'll try isolating GUI to a separate thread or adding a worker thread to the GUI (whatever needs less changes).


Last edited by flaviojs on Wed Jul 11, 2018 7:16 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Jul 11, 2018 7:10 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4679
flaviojs wrote:
However, freezing is essentially a GUI thing and they don't have a GUI, so a thread in Universe doesn't seem appropriate.
The server and AI pretty much actually need to just wait on Universe changes to be processed, before they can usefully proceed to a new task, right. I was figuring that you'd let the thread be an optional instantiation argument-- the server and AIs would leave it null and everything for them would essentially work the way it does now; for the human client it would instantiate the universe with a thread, which could then be used as you are envisioning. But it very well might be best to just make the thread part of the GUI as you are contemplating now.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
 Post subject: ClientUI
PostPosted: Fri Jul 13, 2018 3:06 am 
Offline
Space Krill

Joined: Sat Jul 07, 2018 7:24 pm
Posts: 9
I was trying to figure out where I should place read/write locking and other central thread-related facilities and got confused with ClientUI...

It looks like ClientUI wanted to be a singleton but is not quite there (the ClientUI code does not guarantee 0-1 instances).
HumanClientApp uses his own HumanClientApp::GetClientUI() and ClientUI::GetClientUI().

What is supposed to be the relationship between HumanClientApp (GG::SDLGUI), and ClientUI?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group