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.

DarkBASIC Professional Discussion / DBPro multithread and DLL usage

Author
Message
ale870
17
Years of Service
User Offline
Joined: 17th Jan 2007
Location:
Posted: 8th Jan 2009 00:25
Hello, I'm new as DBPro user, and I'm still learning it.
I have some questions, can you help me?

1) Can I implement threads in DBPro? (multithreading support)

2) Can I use (open) standard DLL in DBPro?

3) Can I execute an external process (program) then "talk" with it using something like pipe (or similar)?

Thank you for your help!

--Alessandro
PEH
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: usa
Posted: 8th Jan 2009 07:30
1) I think some .dll files can run in separate threads not sure though.

2) you can call .dll files if you know the functions
e.g.


3) I've been using this alot lately thanks to IanM's matrix plugin. you can find it here: http://forum.thegamecreators.com/?m=forum_view&t=85209&b=18

let me know if I can help more.
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
ale870
17
Years of Service
User Offline
Joined: 17th Jan 2007
Location:
Posted: 8th Jan 2009 08:15
Thank you for your help! I will check them!

--Alessandro
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Jan 2009 14:38
... and I'll post about this once again ...

DBPro is not designed to be used in a multithreaded environment. Even something as simple as memory allocation (a$=b$, or dim a(10)) could corrupt things, let alone some of the more complex stuff (delete object 1, make camera 1, load image "a.bmp", 1)

If you do create new threads and you get odd crashes, then you know where the problem is, and you're on your own as far as the TGC team and the matrix1 plug-ins are concerned.

I can definitively state that my plug-ins are NOT thread-safe.

James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 8th Jan 2009 19:25
Hey thanks IanM - I had been wondering about how memory is dealt with in this area(any further info would be appreciated), I`ve never bothered with multi threading as I`ve been afraid of locking the core(mentioned at 1st official convention) plus, after testing affinity values I got a little scare when I managed to change most mask values - actually I copied and pasted a little warning but can`t have done it right(was in a rush to get to work). Here is what it should have said;
(This was my response in another thread, relating only to the second link I posted in this thread)
Here you can see how its possible to use multicores in DBP using the affinity mask. Using affinity values of 1,2,4 or 8 will set the affinity for cores 1 to 4 and 17 should allow the system to auto manage them(nowhere near optimal though) - a warning though, I was trying to find the last combination for tri core, when I found it, it changed all values of the mask except 1,2,4 and 8. Hasn`t affected my system but any exe with the name "Example1" followed by "Ux.x.exe" (ieU7.1) will have the same mask value problem as these were the names of the affinity test projects on my system - results in the use of all four cores as one without multithreading, but hangs when the program is exited.

IanM, once again thanks - from the convention I got the impression everything was safe bar the risk of locking the core, I haven`t seen anything contradicting this(not saying it doesn`t exist), so I assumed everything to be AOK with a little risk, I guess you just saved my ass as I was going to face my fear and try getting a thread working tonight. Think I`ll wait for DBPX10 version and hope it deals with this properly (although FPSCX10 utilizes muticore it would appear its only utilised during the build stage - could be wrong though - will have to recheck)
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Jan 2009 22:13 Edited at: 8th Jan 2009 22:14
I'm not going to say that it's impossible to have multiple threads with DBPro ever - that's patently wrong as both the physics and AI plug-ins use threads.

However the way that they do it is to take a copy of everything they need when YOU say so, do all their work in separate threads while everything is completely isolated, then update everything again when YOU say so. It's the PHY UPDATE command that does this. They have their own memory heap to allocate from so they won't corrupt the BASIC heap.

As I said earlier, the memory allocation in your code is not protected because the single-threaded library was used when compiling everything. The memory heap may get corrupted if two threads allocate at the same time, or they may get the same memory area.

Worse could happen when running longer running commands - threads creating objects at the same time could corrupt the structures that are used to record all objects that exist, or the memory allocated, or if one deletes while another is rendering, could crash the renderer. Some of these are things that can't be fixed by recompiling with a multithreaded runtime library.

Unless you design threading in from the bottom up, you aren't realistically going to get it. DBPro simply wasn't designed to allow you to thread.

James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 8th Jan 2009 23:23
Thanks for that, I`m not sure I understand - a little grey in this area - if anything that was created, changed or deleted was all in the first core, can they be accessed in another?
example : Lets say object 1 and memblock 1 are created using core 1, would data read using core 2 be corrupt from memblock 1 or cause a problem? If not then would positioning and rotating object 1 from the memblock data, using core 2, crash the renderer/cause problems? If by chance we were ok so far, would reading the position of object 1 and then writing that data to the memblock using core 1 cause a problem? Even IF this would work, would it be benificial in any way?
I was looking at not having to start the writing of memblock data and then reading from it as I assume the writing would have to be completed before the reading could start. This I was hoping, would reduce reading and writing time from readingtime+writingtime to just writing time. Sorry for being dumb, as I just know your going to point out something really obvious.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th Jan 2009 14:13
Core? Do you mean thread? The processor or core that this is happening on has nothing to do with it. It's the fact that each thread is using the same memory-based structures all at the same time and assuming that each one is the only one accessing that data.

Assume all objects are held in a double-linked list. One thread comes along and starts to delete an object - First it frees the memory, then it relinks the list to remove the deleted object. During that, another thread is accessing that list and accesses the memory you've just deleted ...

Two threads are allocating memory from a routine that assumes no threading is involved ... both threads may get the address of the same memory location. Or they may update the heap structures in such a way as to corrupt those structures.

Basically, just don't do it.

There is no safe way, with DBPro's current structure, to do it without hitting problems in DBPro BASIC code.

If all you want is parallel loading, then there's a plug-in on my site that does this, correctly and safely (eventually - I didn't even manage to get something that simple right the first time).

If you want parallel reading & writing then there's currently nothing available, but I'll think about adding it to the same plug-in.

James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 9th Jan 2009 20:50
Thank you so much for taking the time to explain this, you couldn`t have been clearer. Yes I mean thread! I do try to use the correct terminology, but fail miserably.
I had no idea your plugins did parallel loading, I`ve only ever used them when compiling code provided by others, evidently it warrants further investigation - did I read somewhere you have memblock commands that are faster than DBP ones? I shall re-install and find out. Only just noticed there are two links in your sig, not one!
I hope you do decide to add parallel reading and writing, but thats just me - I think it could be really useful. In the mean time I have a lot of commands to go through, I can`t believe I haven`t looked at these yet. Once again thanks for the information and your time.
Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 10th Jan 2009 01:38 Edited at: 10th Jan 2009 01:47
All DBP and framework plugins are thread-safe in the upcoming release of PureGDK. The current release (1.0.3) is thread-safe for all core DBP libraries when compiling without the debugger.

A user from the PureBasic forum has reported that PureGDK can compile PureGDK applications to a DLL. These DLLs are compatible with PureGDK only.

http://puregdk.com
http://purebasic.fr/english/viewtopic.php?t=32366

Login to post a reply

Server time is: 2024-05-13 11:37:15
Your offset time is: 2024-05-13 11:37:15