Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / [DGDK.net] Handling "Sync"ing with multiple threads..

Author
Message
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 20th Sep 2007 14:52
Link
Hi,
Just though as I am thinking about this at the moment to throw the question open to other people.

I current have the main thread of the application and my component system thread, plus a music thread for handling music playing/fading etc.

The audio one is quite simple and doesn't really impact on anything else.

(The method I use for inter thread communication at present is and event system. All threads share a class called PostOffice which has a delegate for sending messages and each thread has a message handler function which listens to these event messages. This is only a start as I took most the code from another project I've done)

I had an Idea that one thread handles LoopGDK and syncing, and other threads will send sync requests to this thread when needed.

When I get to adding the 3d component I would like that to run in its own thread too if at all possible, and the main game logic stuff running in the main thread.

Any ideas?

Cheers,

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
Back to top
Profile PM Email Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Sep 2007 15:08
Link
There is another message thread in these boards where we discussed multi-threading a lot.

We covered how "even if" DarkGDK is/was threadsafe - you'll probably have contention where the code meets the video driver unless you have two cards. At the hardware level - you need to have a controlled i/o port communication (single thread) because there are interrupts usually associated when moving data this way. Newer cards likely have direct MEM to GFX mem copy - but even that needs to be "Critical section" (Controlled mutex I thnk its referred to in WinAPI nonmenclature) or single threaded to my knowledge.

This isn't to say DarkGDK doesn/t already have code to deal with that. It may be none issue.

Also - the other thing to really consider (Like your music issue - I can see that as not a big deal) the demand of the two threads. If they both need to be "Churning" than you need to write code that allows the other to "run" - usually telling the OS - "I request you to relinguish my current ability to crank code so my brethren can have a turn" - Though with the newer multi-core processors - this is possible less of an issue - especially with regards to proper "Processor Affinity" usage .. where you delegate what CPU you want a thread to run on.

Question everything I say! (Because WinAPI model for Mutex'n I'm not an expert at nor do I know the inner workings of DarkGDK nor the Windows DirectX internal with regards to Hardware layer->Meets Driver->Meets DirectX (controlled by OS etc)


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY
Back to top
Profile PM Email Website
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 20th Sep 2007 15:31
Link
All the calls to DGDK are already sync locked (VB/.net version of mutexing) so at the end of it all, only one thread will be using a component of DGDK at one time, e.g.



and



The two examples above can run at the same time, but only one thread can access oDBImage at a time and the same goes for oDB3D.

I've managed to have two threads running and accessing the various functions and the only issue I have had is when a Sync is required. Hence the idea of one thread handling the Sync and LoopDGK.

Due to the nature of the Component system (2d UI) this currently doesn't need an aggressive loop so it does a Thread.Sleep(10) in the loop. It still seems very responsive but the CPU usage hardly goes up when running the program. Again this may change later if things require it.

The music thread is also of a similar vain, so doesn't require an aggressive loop so also has a Thread.Sleep(10)

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
Back to top
Profile PM Email Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Sep 2007 16:27
Link
That is REALLY cool they set it up like that!!!

Sleep in a wonderful call isn't it? When I first was making my multi-threaded "CGI Server" (Before it became a standalone Web Server and/or integrated CGI Server as an option) I worked really hard to make it all perfect - tight etc. Efficient. But the CPU would go Bananas and the threads didn't fire off very well like designed. I added the sleep comand and it was LIGHTNING!

(Now as I tend to gloat - I have the fastest web server I've seen yet!)


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY
Back to top
Profile PM Email Website
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 21st Sep 2007 01:11
Link
After some experementing it seems that the main program thread is the only thread allowed to issue a sync. If you try to issue a sync from any other thread it blocks until the main thread does a sync.

So I've just swapped around my code so the dgdkStuff is now in the main thread and the game logic is in a seperate thread.

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
Back to top
Profile PM Email Website
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 21st Sep 2007 01:26
Link
jasuk, remember this though, if Sync is called irrespective of the thread, the Sync function will wait until the Vertical refresh of your monitor, i.e. 60mhz for most monitors, so it matters not which thread calls the Sync, if it's waiting for the refresh, the other threads will also hold until the scan has completed. so basically, you're forcing ALL threads in the queue to wait until the monitor has refreshed. Possibly?

Paul.


---- The Meridian Culmination ----
Back to top
Profile PM Email Website
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 21st Sep 2007 01:52
Link
Hi Apex, If I do sync in the main thread the display updates as expect, if I take exactly the same code and run it in a new thread it will lock indefinatly it seems (I've waited around 30 seconds), unless you do a sync in the main thread, then it will carry on till the next sync and lock again.

In my code, I've swapped around the threads so that all DGDK stuff now happens in the main thread and the game logic code that used to be in the main thread is now in the seperate thread. Everything now works ok.

From what I've seen experementing I can do any other DGDK command in the second thread, but the sync has to happen in the main one.

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
Back to top
Profile PM Email Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Sep 2007 02:06 Edited at: 21st Sep 2007 02:18
Link
Sweet. Thanx for reporting back that test result - that is good to know.

[EDIT]
@APEX - Just Read your comment above - missed it earlier (Responding to emails yada yada) And that would be an example to me maybe why adding a thread isn't the best dilly - ESPECIALLY in .Net which already has more overhead than C++. I mean swapping tasks - many are just "used to" but I used to write operating systems as programming challenge - and frankly - even straight assembly language code - there are a lot of steps required for a task swap - and that's considering a CPU (x86+) designed to handle task segment register, various memory models tc etc.


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY
Back to top
Profile PM Email Website
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 21st Sep 2007 02:18
Link
I just think I should add, that all this is running on Windows Vista 32, just in case its something strange with vista that causes this result (All my PC's are now vista so I do not have an XP machine to test agains anymore)

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-11-19 16:46:45
Your offset time is: 2024-11-19 16:46:45