Multithreading started

After my studies have taken my brain for quite some time, now I am able to combine both! In April I will take an exam on “Betriebssysteme, Rechnernetze und verteilte Systeme” (operating systems, computer networks and distributed systems).

So I decided to apply my new knowledge to BlueWar, starting with thread support and (I hope my time will suffice) a revival of the multiplayer mode will follow.

As a first step, I upgraded the BlueWar Dependencies:

• Ogre 1.61 Source compiled with THREAD_SUPPORT 1
• ETM 2.3.1
• NaviLibrary 1.8 Pre-Release (SVN Awesomium) see here
• MouseCursor see here (new! because Navi removed cursor)
• PagedGeometry 1.05
• boost 1.37 (new!) – for now I only use boost::thread, as it seemed a great, simple solution for threads and is used by Ogre

Von BlueWar Screenshots

Then, a careful review of the loading process was inevitably:

When a map is selected in the main menu (new!) and loaded, the loading screen (new!) has to be updated while the background thread is building the new scene. I found lots of small interdependencies between the two, which were no problem in a single-threaded environment, as the CameraController. The “CameraController::Init” method attached the Camera to a viewport of the main window, which made things horrible if the main thread was currently rendering! I moved the viewport code to the firstUpdate. Another example is the FrameListener, which must not be added while the main thread is accessing the FrameListener list.

Now I hope that the major raze conditions are found, the only rendering lock required at this moment is the FrameListener initialization. Another lock is used by the InputManager so that its a quasi-monitor. This way I can be sure that no one is going to add listeners while using them – yes I know, this is the reader-writer-problem and it would be possible to have multiple readers at a time, but I really don`t have that many calls to the InputManager, so forgive me!

As a test, I also moved the Navi updates to a worker thread. This works pretty good with some locks (although I`m quite sure it can be either enhanced or dropped, because Navi itself already uses a background thread). I still have to look further into the details of boost::thread::sleep, because when I do

static bool navi_update_continue;
void navi_update()
{
	NaviLibrary::NaviManager& mgr = NaviLibrary::NaviManager::Get();
	navi_update_continue = true;

	boost::xtime update_interval;
	update_interval.sec = 0;
	update_interval.nsec = 50000000;

	while(navi_update_continue)
	{
		MUTEX::scope_lock lock(MUTEX::Navi);
		mgr.Update();
		boost::this_thread::sleep(update_interval);
	}
}

the thread sleeps not at all (at least not noticably).

The next vision for me is to use multiple threads during gameplay, and I am quite positive about that after this fast success! I promise not to let you wait another year before the next post

Advertisement