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.

Code Snippets / [DBP] + [Matrix1Utils] Multi-Theading

Author
Message
DigitalFury
13
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 4th Dec 2010 23:31 Edited at: 15th Sep 2012 00:59
Multi-Threading


I finally figured out how to get multi-threading to work! You need Matrix1Utils for this to work.

Removed!

Untested:
- Create an array in a thread
Any ideas of some commands to test?

You might want to check out the Multi-Threading Tutorial here:
http://forum.thegamecreators.com/?m=forum_view&t=178927&b=1&p=0

This snippet might be used in my project Zombie Project: Early WIP.

Any comments, questions, or bugs let me know. Don't forget to credit me if you use any of my code.

DigitalFury

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 5th Dec 2010 01:49
The problem with multithreading in DBPro is that there is very little you can actually do safely, simply because the libraries were simply not designed with multithreading in mind

For example (and this is the usual thing that multithreading is wanted for) if you are loading an object in a thread, you can't do anything else with objects in another thread, including displaying them, in case the internal object list is being expanded.

Now doing something like grabbing keystates in a thread could be relatively safe, as long as the array you store the values in is preallocated and doesn't contain any string values.

That's why I implemented co-routines, but not threads in my function pointer plug-in - co-routines were actually harder for me to implement, but I could guarantee that they'd work whereas I couldn't with threads, and certainly not for my own plug-ins.

DigitalFury
13
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 5th Dec 2010 02:03 Edited at: 5th Dec 2010 02:06
@IanM - Thanks. I actually gave a tutorial on how to use your co-routines commands. They do work nicely. If I could figure all the limitations of Multi-Threading posted here then that would be awesome. Any other limitations you know of?

Thanks again,

DigitalFury
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2010 19:43
That's like asking 'how high is the sky'. The problem is that DBPro wasn't designed with multithreading in mind at all, so even the most innocuous things could cause you problems:

Creating or deleting anything, accessing anything when it is being updated, accessing the same thing from different threads.

'Anything' includes (but is not limited to) anything that is accessed during SYNC (sound/music, objects/sprites - and therefore images too), memblocks, arrays... the list pretty much covers the whole of DBPro.

My personal view is that there are so many limitations to multithreading in DBPro that you may as well not bother.

DigitalFury
13
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 7th Dec 2010 20:38
@IanM - Ok fair enough. I'll test this for myself and hope that it works. Otherwise I'll check out Dark GDK or Pure GDK.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2010 21:45
As they use exactly the same code behind the scenes, they have exactly the same problem.

One thing I can think of that could be carried out at the DBPro level for multithreading is if you can capture all the starting values you require into arrays, then you can put secondary threads to work on calculations, and when they are done, use the main thread to apply the resulting values.

For instance, you could maintain an array of object positions and orientations and have the AI operating on them in a thread - the only thing you'd need to take care of in the main thread is snapshotting the results at appropriately safe locations in the logic, updating the objects from the calculated positions, and displaying the results.

That's how DarkAI does it, and DarkPhysics uses a similar technique (via the PYS UPDATE command).

Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 7th Dec 2010 23:29
I beg to differ, IanM. PureGDK provides complete thread safety for all DBP commands as well as any additional all plugins.

Regarding thread safety in DBP:

http://forum.thegamecreators.com/?m=forum_view&t=128257&b=6

Quote: "My experience working with DBP and threads through the development of PureGDK has led me to the conclusion that is is generally unsafe to use threads in DBP because even when sync is on. This is because DBP either calls certain functions internally or uses the same resources as other functions which can lead to an invalid memory access crash when encountering key commands such as For/Next, Do/Loop, Sleep, Wait, etc."


Thread safety is possible in DarkGDK with manually locked mutexes, semaphores, or critical sections. But in PureGDK, this functionality is integrated transparently to provide thread safety code out of the box. No need to implement your own!

http://forum.thegamecreators.com/?m=forum_view&t=177817&b=38

This is more than a simple port of DBP. Large portions of the engine have been rewritten to provide enhanced functionality, greater speed, and more flexibility. And the best part is, if ever you choose to switch to a different language, you get to take the engine with you!

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Dec 2010 18:54
Yes, I've seen your email, and I withdraw what I said previously about the PureGDK port.

However (and correct me if I'm wrong), I think it's still the case that you can't, for example, load an object while syncing as each thread gets unique access to DBPro/GDK - loading that object will make the sync wait, or vice versa.

Whether that's the case or not, you can't do multithreading safely in DBPro, and only do multithreading safely in C++ if you implement a scheme similar to your PB implementation.

Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 8th Dec 2010 22:41 Edited at: 8th Dec 2010 22:59
You are correct that most DBP functions are not actually asynchronous. However, certain functions that are known to be safe can be identified as "NoSafeCall" in the code templates and are exempt from the thread safety code. Specifically in PureGDK, the 3D Math and most of the Input library are known to be safe.

Locking synchronization on the entire engine instead of a specific code block is simpler to implement if you want immediate results. But there isn't anything to stop someone from disabling the built-in multithreading and implementing their own.

Another advantage of PureGDK is thread-aware error handling. A specific error that occurs in one thread remains known despite other errors which may occur in other threads. Additionally, runtime errors in the engine do not halt the program, as it does in DBP.

I don't know exactly how DarkGDK works internally with runtime errors, but from what I do know about DBP's error handling, it's more like C's "errno" which can return unexpected results in a multithreaded application.

PureGDK is unique in that it was designed with thread safety in mind from the ground up.

Login to post a reply

Server time is: 2024-03-28 09:05:54
Your offset time is: 2024-03-28 09:05:54