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.

DLL Talk / IanM's utilities + Torrey's multithreading = harmony in DBPro or disaster waiting to happen? Theories inside.

Author
Message
Drac
20
Years of Service
User Offline
Joined: 10th May 2004
Location:
Posted: 25th Mar 2007 09:36
****WARNING*********THEORY TALK**********WARNING****

I was scouring the forums the other day and ran into Torrey's multithreading dll. At first I thought the multithreading would be more of a novelty because of likely stability issues within dbpro, but the more I thought about it, I think I may have found a way to make it work in a stable manner.

One method I decided to try was separating the code into threads of different subsystems(rendering, physics, networking, input) and making a separate thread as an event handler. Not only would this help limit access to shared rescources, it allows each thread to run independantly and have an idle time each loop thanks to Ian's optimized wait and ticker commands which will help control overall cpu usage per thread. In a way, it lets you have a thread running faster or slower than another thread. The event handler will be responsible for recieving messages from each thread and making sure they reach their desired location. I believe IanM's mutex commands can help stabilize that as well, but cannot confirm it as I have not properly tested it.

Obviously, this approach is severe overkill for a smaller project. But for a larger project I would like some input as to the validity of my theories. In particular, I would like some insight as to the usefulness of such an architecture or possible alternative methods.



Below are the links to the threads in which the plugins can be found.

IanM's Utilities
http://forum.thegamecreators.com/?m=forum_view&t=85209&b=18

Torrey's multithreading dll
http://forum.thegamecreators.com/?m=forum_view&t=68623&b=1

Do, or do not. There is no try.
-Yoda
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 25th Mar 2007 19:28 Edited at: 25th Mar 2007 19:34
Quote: "One method I decided to try was separating the code into threads of different subsystems(rendering, physics, networking, input)"

To me that seems like making the entire process harder, due to having to completely synchronize everything to avoid race conditions. Each of those parts you mentioned will need to access the object data, so other threads will have to pause while one executes.

The way that I see it is that if you handle rendering and physics in separate threads, you'll need to keep a global data structure for the rendering thread to make a local copy from. And even then, doing this in DBP doesn't seem possible unless the physics/rendering system only tries to access this local data.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 26th Mar 2007 00:28
@Drac,

I thought about adding multithreading to my function-pointer DLL, but decided against - just looking at the source code a few of my plug-ins made that decision for me immediately.

Multithreading isn't something you can just add as a top layer - it has to be built in during design, and it's more than just compiling using a multithread version of the C runtime. Basically, my plug-ins are not thread-safe. They are full of unprotected variables and structures, with race conditions all over the place unless run in a single thread.

After a quick scan of my plug-ins, here is my first best guess on the readiness of them for multithreading:


Note that this list says that plug-in numbers 3 (synchronisation) and 2 (tickers) are not thread safe - two plug-ins that you want to rely upon.

I spent 15 minutes compiling this list from a quick glance of the source code - it's not definitive. If this list says it should work, but you can't get it to, then you have to live with that.

The number of issues I've spotted in 15 minutes with my small codeset should give you an idea of the number of issues that will be present in the far larger codeset making up DBPro.

Drac
20
Years of Service
User Offline
Joined: 10th May 2004
Location:
Posted: 26th Mar 2007 03:15 Edited at: 26th Mar 2007 09:21
@Benjamin - after spending some time with the idea, I agree with you on the complexity issue. As far as a global data structure for objects I also agree, it would be better to keep all things that require the object's data directly together or else risk having to pass a local version from thread to thread each loop.

@IanM - It seems like the synchronization should work as long as you create all of your mutexes before the other threads are made and delete them after the threads no longer exist. The ticker commands were more of a nicety than anything.

I do know one thing, it's a beast to impliment safely and efficiently.(why i'm trying to find a good method for it)

[edit]
You are right guys, unless i were to lock the whole game system for each thread's loop (which would defeat the purpose), there is no way to gaurantee stability in dbpro. There is no telling which dbpro commands will work and which won't, and which ones even look like they work for a while but bite ya later.

example..


this appears to work okay until you press CTRL-ALT-DLT(silent crash)

simply adding a command like Set Camera to Follow causes an instant crash and memory error(it probably uses a maths dll for calculations which i am using elsewhere).

Oh well, it was fun trying.

Do, or do not. There is no try.
-Yoda

Login to post a reply

Server time is: 2024-11-22 17:20:55
Your offset time is: 2024-11-22 17:20:55