Multithreading
BlitzMax Forums/BlitzMax Programming/Multithreading
| ||
| Hi, Is there an official statement available if - and when - one of the next BlitzMax releases will officialy support multithreading? I am sure that I am not the only one who is in need of that special feature. ;-) Thanks, Winni |
| ||
| I dont think it will. |
| ||
| I dont think it will too, I havn't heard Mark mention it anywhere. I have uses for it though! |
| ||
| Yeah. Multithreading would be awesome, I'll need them real soon too. Unfortunately I wouldn't expect it until after Max3D tho' - unless there's some dual-core revolution right around the corner. |
| ||
| I don't think even Max3D will change it as the GC just is not multithreading safe. But I agree, Max3D will be in need of multithreading due to physics and terrain. |
| ||
| See the free process library, standard part of Max. Or make a multitasking script execution system. |
| ||
| AngelDaniel: I'm afraid I don't follow. What free process library do you mean? In any case, launching additional processes is not necessarily what I want to do; spawning worker threads for certain tasks is more the direction in which I want to go (and what I have been doing in other programming languages). I am currently toying with a little communication server project of mine, and the idea is to have a worker thread for each connection plus additional threads for maintenance and other tasks. Yes, this probably could be implemented with multiple processes, but I think it is more elegant and efficient to just multithread it. Basically, I just want to find out if BlitzMax can be used beyond the scope of writing games. And since the language is so cool, I think it should be possible. |
| ||
| Take a look at this: http://www.blitzwiki.org/index.php/Threads_(Module) I'm making a little HTTP file downloader with it. Its very picky, and very easy to crash, but it works. |
| ||
| I tried the freeprocess thing. But my main problem is that writting / reading to the streampipe somehow does not work as I thought and wanted it to work (at least it does not allow me to do a "conversation", which was the main point of it) My next try will be freeprocess + GNet, I'm sure that one will be a larger success. (wanted to do a threaded loader for media etc) |
| ||
| See the free process library, standard part of Max. Processes do not share the same resources, and thus cannot possibly replace multithreading. Or make a multitasking script execution system. While user threads could address the problem for single processor machines, you would need proper kernel threads for dual-processor, dual-core blade servers. |
| ||
| Ask Mark is easier solution. |
| ||
| Answer last time (longer ago) was no due to the GC |
| ||
| No multithreading in the future? That way BlitzMax is worthless for me. Another features Java has that Blitzmax doesn't. |
| ||
| Within a year or two, it will be impossible to get a new machine without at least a dual core CPU. In the Mac world, where I am using BlitzMax, we have already reached that stage. And they way it currently looks, it is even more likely that in two years all new computers will be quad cores. If there were no other reasons to ask for multithreading support, that alone would be reason enough. Personally, I am more interested in multithreading than 3D support, for example. I am interested in BlitzMax because it is a nice, straight-forward, powerful and completely unbloated language. Maybe I have the wrong approach towards it, but I would love to use BlitzMax for (communication) server and client-side developing. With multithreading support in its kernel, I know that I can do it. Without multithreading, I know that BlitzMax is a dead-end street for that specific purpose. It's that simple. Launching several processes and implementing IPC through sockets might be feasible in certain areas, but I think in most cases it's just overkill and inefficient. I do not want to waste my life with Objectice-C, Mono on the Mac is nowhere near BlitzMax (except for server development, where it is lightyears ahead of BlitzMax), and I never got a grip on Java. So I have very selfish reasons to ask for mulithreading support. ;-) BTW, I would not mind paying for it. If Blitz Research wants to sell this as a commercial module in the same price range of the MaxGui module, that would be fine with me. But in any case it would be great to get an -- official -- statement from the developers. :) |
| ||
| threading through module is not possible. The GC itself must be replaced to make it possible. There have been some "intelligent" users that created threading modules for Windows and the Unix based but it seems like they never tested them on a multi core / multi processor system or they would have seen their apps crash. |
| ||
| Hi Dreamora, Yeah, I know at least one of those modules and played with it a bit. During the few tests it did not crash on my iMac Core Duo, but I know that this was just luck. I have worked for a compiler vendor before and know how tricky multithreading can be, especially when a Garbage Collector is involved. When I suggested having a thread module, I was more thinking about it in terms of a sales concept. Definitely the BlitzMax kernel itself must support multithreading, but the user level functions and classes for it could be placed in a separate module, to they can charge for it if they intend to do so. |
| ||
| I really wish there was a no GC option in Max. |
| ||
| Contrary to popular belief, the GC is not to blame for the lack of multithreading. Both C# and Java have a thread-safe GC. The problem is that BlitzMAX does not have a mechanism for preventing consecutive access to shared resources (like a monitor). No multithreading in the future? I wouldn't accept Dreamoras off beat comment as the single universal truth of the intentions of BRL. I really wish there was a no GC option in Max. There are. Several. However that would not eliminate the need for a mechanism to prevent consecutive access. |
| ||
| From Mark's worklog... I also had a quick play with building a 'threaded' version of Max. This is something I am definitely interested in, but will not be getting into until at least after we get the new compiler+GUI stuff out. Like auto flushmem, there's more too it than initially meets the eye. But I did at least get a (very) ropey "load images with progress bar" thing happening and have a rough idea of what will be required. I wouldn't take it as as gospel, but at least we know it's being considered. |
| ||
| The part with "auto flushmem" shows how old this log entry is. FD: I did not say never. But thats what was mentioned when it was asked the last time. That it won't happen in the forseable future. Ok on the other side: who knows what BRL is working on? Normally we see it when its there (or sometimes even after it or how many realized that one of the syncmods last week solved the "instable TLink" problem with TList? :P) |
| ||
| "Its very picky, and very easy to crash, but it works." Yeah, that sounds like multithreading alright. :) |
| ||
| @WarrenM hit it on the head there! LOL! @dreamora armed with 1/2 the facts as usual I see @Nomen luni - probably the best thing in max... better than what c++ does... Lets face it this isnt what Mark does full time, give the guy chance, he'll suss it and like I think he'll suss shaders in an easy to use manner... (now that will be an achievement...) |
   |