Threading on Linux
Archives Forums/Linux Discussion/Threading on Linux
| ||
| I found this Topic: http://blitzbasic.com/Community/posts.php?topic=48782 But I'm a Linux-User, and so i can't use this very usefull Module. So i tried to create a Threading-Module for Linux. (Edit: Now its for Mac too, i hope) And it works good! Here the links: http://clonk-point.de/files/Threading.tar.gz http://btbn.de/Threading.tar.gz Ps.: Kev's Windows-Threading-Module is includet in this Module, so you must not use 2 different Modules for 2 diffrent OS. Thanks Kev for this Windows Threading-Module! |
| ||
| Very interesting and useful. Thanks! I think i'll use it to optimize robotics functions(ie: acquire images, process old ones, decide what to do, execute all at the same time). |
| ||
| Is there any way to get informations about the running function from within the main program? I mean: is it yet finished? or something like this. |
| ||
| Note: BlitzMAX is not reentrant (thread safe). |
| ||
For MacOS only somewhat small must be changed:Import "-std=c99" ' <-- here, Import "-lpthread" it does not give... Import "linthread.c" Extern Function CreateThread(threadfunction())="bmx_createthread" EndExtern Save this as macthread.bmx And add the following lines in thread.bmx: ?macos macthread.bmx ? Build modules... thats all... |
| ||
| @morszeck: Someone in the german forum was faster than you, I implemented it with his help(it was rema) @SpLinux: At the moment not, but i'll try to enable more functions for Threading. @all: I tried to implement threading for Mac, could someone test it for me? The links are the same. |
| ||
| You can't use threads with blitzmax. It crashes unexpectly and messes up constantly. The garbage collector needs to be made thread safe otherwise even code that is thread safe it's self will still fail to work. |
| ||
| For robotics apps security isn't a problem. It's not like programming a web browser, whose bugs can be used by malefic code. |
| ||
| For robotics apps security isn't a problem. Random crashes due to non-reentrant code is a problem for any app. You can't use threads with BlitzMAX. |
| ||
| Have you ever programmed robotics apps? I think no. Robotics apps need to do many things as faster as possible, and so most of the time they are build up of modules and dlls. I, for example, use a main program to call other ones to do minor things. If a minor program, which has a few millisecs of life time, has some low possibility of chrash: 1)it doesn't matter for the main program; 2)it doesn't crashes the main program; 3)there is a lower and lower possibility to crash due to his low life time. |
| ||
| And this module uses os native functions, whose that the os os uses for all the programs. On Linux i don't see apps crashing very often. And with BMax is perfectly possible to use threads. |
| ||
| I have tested this Threading-Module now on my Ubuntu Linux an it works perfectly. No crashes or something like this. How is it on Windows? |
| ||
| I'll try it by a few moments. I'm downloading mingw. PS: it perfectly works on Linux to mee too. |
| ||
| I have some problems with mingw on win, so i can't compile the mod. :( If anyone can compile it, could put online yet compiled, so i'll be able to use it on win too? |
| ||
| I think no. Well you're entitled to think whatever you want. If a minor program, which has a few millisecs of life time, has some low possibility of chrash: Except since you're using threads, not processes, the data used by the forked tread is the same data that's used by the main process, thus corruption in onw, will spill over into the other. And this module uses os native functions, whose that the os os uses for all the programs. It has nothing to do with kernel threads or user threads, but to do with simultaneously reading and/or writting to/from the same memory (an undefined operation), known as the critical section of a program. On Linux i don't see apps crashing very often. THat's because on Linux, most multi-threaded programs are reentrant/thread safe and implement a synchronization scheme to prevent critical sections from being executed simultaneously. And with BMax is perfectly possible to use threads. I didn't say it wasn't possible, I said it wasn't safe! PS: it perfectly works on Linux to mee too. Well on a single CPU computer the chance of two critical sections being executed simultaneously is very slim, so most of the times it will work fine. Ofcourse in a multiple processor environment, the risk goes up exponentially as the number of CPUs increase linearly.But hey, if you want to send a robot into production with potentially fatal flaws in its programming, that's your funeral. |
| ||
| Maybe someone could support Mutexes? These allow threads to read and write data on a first-come first-serve basis. (A thread locks an area while it's using it, and then unlocks when it's done. Threads check to see if an area is locked first) Could be useful. Russell |
| ||
| <ot> @morszeck: Someone in the german forum was faster than you, I implemented it with his help(it was rema) i'm rema in german forum: Darum ist mein Englisch auch so miess. Siehe mal mein Profil an! </ot> |
| ||
| @ FlameDuck: But hey, if you want to send a robot into production with potentially fatal flaws in its programming, that's your funeral. I'm againist robot selling, the robots i make are for research ONLY. I use robot specific code and single processor computer. If i wanted to power up the robot calc speed, i would use more computers linked with ethernet, and not multi processor computers, so i would have faster speed. Well you're entitled to think whatever you want. Did you make any computer controlled robot? |
| ||
| Knowing of a fatal problem, knowing how to avoid it and still using it is just bad coding practise ... ask Microsoft, they got kicked for that with Win95 and Win98 over and over again. *and yeah, programmed a robot already ... we did them in our project time this year. Mind Storm Pacman ...* |
| ||
| The fatal problem would be that BMax crashes with threads? It didn't crash to me, and i've executed hundreds of times. And how to avoid it would be not to use this module? I'll still use it because it's a good module. And it doesn't crash. Has it crashed to you? |
| ||
Using the code below all it does on mine (Windows) is call the function at the "CreateThread(TestThread)" line and then carry on. Looks like its still in the same thread.SuperStrict Import btbn.thread Global Done%=0 CreateThread(TestThread) While Not Done Print "Running..." Delay 500 Wend End Function TestThread() Print "Thread begin" Delay 5000 Print "Thread end" Done=1 End Function Output: Building untitled1 Compiling:untitled1.bmx flat assembler version 1.64 3 passes, 3782 bytes. Linking:untitled1.debug.exe Executing:untitled1.debug.exe Thread begin Thread end Process complete |
| ||
| To me it works perfectly. It prints: Thread begin Running... Running... Running... Running... ... Thread end |
| ||
| Do you have global variables you access in the thread and in your main program? |
| ||
| The King Dave's example has global variables shared. |
| ||
| it does work correct, only thread variables need to be global. what the thread.mod does is get the address of the function and call that in its own thread. well the win32 version anyways. kev |
| ||
| Yes. It was written on your post for win32 threads. |
| ||
| heh.. i made a thread mod for windows a while back, and it worked rather nicely too. that is until i tried using it for some real tasks (a http server feks) at which it crashed like hell, even when i tried using locking. it might have been my particular implementation of it, but im with FlameDuck on this one, even if it works, its highly unsafe and unpredictable. |
| ||
| I'll still use it. I don't see the problems you have found. |
| ||
| im not sure how stable bmax and thread mods would be but knowing FlameDuck history of mostly always being right. i to guess im with him. but i would say still use it although it does need lots of people to test it. kev |
| ||
| I've run it many times and it never crashed. |
| ||
| I've run it many times and it never crashed. i have also, never crashed here. |
| ||
| And so? |
| ||
| Hmm.. i guess i should try your version then on my http server, just for kicks ;) |
| ||
| Maybe it depends on usage: for example if you access the same resource at the same time you could have a dead-lock, but i think the threading functions the lib use would prevent it. |
| ||
| I agree with FlameDuck here. Threading in BMax is currently unsafe and should be avoided. He already listed the reasons, so I see no use in listing them again. Writing unsafe code is bad practice, so why you're doing it is beyond me. Especially for robotics, that just seems suicidal. What if it does fail? What happens then? On another note, wouldn't it make more sense to write the code for the robot in C and thus gain a 20% speed increase? Since you seem to think that speed is very important for a robot (I'm not saying it isn't, seeing as how I don't work in robotics), this would probably benefit you -- plus, you could use threading safely as long as you did the work correctly. |
| ||
| In BlitzMax the simplest solution I've found is to make your program reentrant and have it run itself which gives you a nice safe multiprocess environment. The FreeAudio module starts up a thread in the Linux implementation so if you want to write drivers for external engines you can easily add threading to the native glue you write for the module as the toolchain is all setup to support the pthread model. I don't think BlitzMax itself will get multi threading until it gets multi processor support. Currently BlitzMax IS NOT THREAD SAFE and hence BRL do not support or advise any attempts that could see blitzobjects changing reference in anything but the core thread of the process. I thought I knew everything about threads until hyperthreading came out for the P4 and the idea that every clock cycle multiple processors are contributing to the state of the machine is just daunting (code that is safe in preemptive scheduling will explode instinctively when placed in a parallel scheduled environment). |
| ||
| @Noel Cower: i need to do computer vision programs, and i not know how to do that using c/c++(it would take so much time to learn it, and i don't have time). To me it correctly works, and i don't have a multiprocessor computer. The code won't be re-distribuited, and so there won't be problems for other people too. @skidracer: freeaudio uses the same includes as the BMax module we're talking about. Yes, with multi-processing threading would be faster, but i see many good points to do that on single processors too. It would make programs faster too. |
   |