Multithreading
BlitzMax Forums/BlitzMax Programming/Multithreading
| ||
Hello, I was doing some searches to see if multithreading is possible in BlitzMax. I found a couple of references to a unofficial module that adds support for it on Win32 but can't find this module. If you know where I could find it could you point me in the right direction please. Also, is there any chance there will be an official module for multithreading? (even if its not available on all platforms). |
| ||
Not yet. Although someone did get a Win32 only version working - Antony? or skn3ac? |
| ||
Yeah I saw the name Antony on another thread. I have used multithreading in C++ before, but I'm not familiar enough with BlitzMax yet to get it working as a module. |
| ||
Also, is there any chance there will be an official module for multithreading? Well there's always a chance. Whether it'll be before or after the 3D module is anyones guess.The main probelm I see with using BlitzMAX in a multithreaded environment is that it's not thread safe, and some of the more advanced features (like garbage collection, and the GUI) are going to have you pulling your hair wondering why things just crash at random (if you're lucky). |
| ||
I believe in one of Mark's worklogs that he has had a bit of a look at this already. |
| ||
Here's the link for the threading module. http://www.blitzwiki.org/images/b/b4/Grb.threads.mod.zip Here's a link to some info about it on the wiki. http://www.blitzwiki.org/index.php/Threads_(Module) |
| ||
Great! Thanks for the link! |
| ||
As far as I know Drago has also written such a module. Though I don't know if his is for public use. Do you plan to port freeworld to bmx? :) |
| ||
I plan to at least port the server to bmx. Main reason I need multithreading is to ensure a client can't lock up the server by not reading its incoming data. This has been a nightmare for me with blitz3D and there is no guaranteed way to avoid it. However with multithreading I can do it :) Once the official 3D module is released I will consider porting freeworld itself across to bmx... however I fear too many differences will exist. |
| ||
however I fear too many differences will exist. You should probably hold off on the angst for now. How is freeworld doing BTW? Can't seem to find mention of it on MMORPG.com anymore. |
| ||
@King Dave: To convert the whole FW project to BMX will be pure pain! It might get a bit easier when the official 3D module comes out, but still a huge task with no visual progress at all. |
| ||
with no visual progress at all. a) You don't know that for a fact.b) A massive speed increase is visual. |
| ||
Any chance to get a link with this ? Can find him. Grb.threads.mod.zip |
| ||
Threads don't work stable on multicore systems as the GC is not threadsafe. The GC does not even work with external processes stable like the ones in DLLs if you have callbacks, it will take a few seconds at maximum until BM does with a GC C code error. |
| ||
Hum ok, thanks for reply. |
| ||
Threads don't work stable on multicore systems as the GC is not threadsafe. Or on singlecore systems, although the risk of running into concurrency issues is greatly reduced, particularly if you have a slow processor. |
| ||
You don't need your code to be threadsafe. You should use thread-unsafe code whenever you can. You just need a way to lock the threads when a global variable is being written to. That is the only time the threads can affect one another, so you do something like this: If SomethingSomething LockThreads() myvar=1 UnLockThreads() EndIf Locking threads slows the application because all threads must momentarily pause. A better way to handle this is to use arrays, with one value for each thread: If SomethingSomething myvar[ ThreadID() ]=1 EndIf Calling GCSuspend() before a multi-threaded section might help. However, my tests using BlitzMax callbacks with a multithreaded Newton simulation have always crashed unless I lock the threads. |