Some commands for dealing with multi-core platforms would be nice. Basic thread creation/killing/variable locking. It would be nice to spawn off the odd subroutine to a different core. No small task for Gernot though, I understand but no harm is asking. ;)
There is an INLINE wrapper for my internal threading functions.
Wait...
oh. I'll attach it.
[attachment deleted by admin]
Hier h?tte ich eine kleine Frage:
Funktioniert hier Variablen - ?bergabe zwischen verschiedenen Threads ?berhaupt, oder werden diese als getrennte Module behandelt?
Normalerweise funktioniert es ja nicht, oder?
Gru?
W.
Quote from: Kitty Hello on 2009-Sep-22
There is an INLINE wrapper for my internal threading functions.
Wait...
oh. I'll attach it.
This is really good stuff Gernot, many thanks! :D
@WPShadow... In the way of a polite request, can we keep a thread in the language that it was started in please, otherwise it gets very confusing for the author... :whistle:
The idea's cool, but I don't have the foggiest how to make use of it in my programs... =D
ups, really sorry! I'm very confused at the moment... :'(
The question for me is, if there's a way to give (for example) an integer from a threat to an other?
Yes, you can access globals from both threads. But you must make sure that noone's writing to a variable when another one reads from it -> crash.
That for you need "Mutex" objects, that can be used as a lock.
Sound's good, I'll try...
Quote from: WPShadow on 2009-Sep-24
ups, really sorry! I'm very confused at the moment... :'(
No problem Amigo! ;)
Gernot, this is one of these in-lines that is SO powerful, that you have got to wonder why its not part of the command set? It would definitely add to the selling power of GLB if it had the line "GLBasic with full Multi-threading Support!".
Mutex are multiplatform , right?
Quote from: Ocean on 2009-Sep-25
careful here! Before claiming 'full' multi-threading support you need a runtime library that is fully thread-safe. GLB's runtime library is not.
Perfectly true, as GLBasic is a cross compiler and GCC has got quite good thread support already, it may (Or may not! :P) be a reasonable feature to implement?
You didnt need it for games, i think... =D
If you want big landscapes or a MMO game, you need MultiThreading, otherwise the program would have really bad FPS... Or if you want to load the mediafiles in the background.
Quote from: Schranz0r on 2009-Sep-26
You didnt need it for games, i think... =D
Your right, you don't "need" it to run your game but wouldn't it be preferable to allow the programmer to have the option to use it?
Especially considering how nearly all modern processors are now multi-core?
The big problem would be : Is SDL multi-threaded ?
yepp, its threadsafe!
GCC has no multithreading. It's the POSIX or Winodws library that has. And I have that wrapped in the attached project. It's multiplatform, yes.
So all the graphics, sound etc can be done in a seperate thread ? Or would it be best to limit it to logic and associated stuff ?
it would be best to ignore threads wherever you can. Honestly.
If you want physics in anouther thread, so that. But be aware of the overhead you create.
So OK to use or not to use? :doubt:
I have been using threads with other languages for years, I'm pretty sure I would only use them in the right situation IF its OK to use them.