Physics + threading = Headache! suggestions welcom
BlitzMax Forums/BlitzMax Programming/Physics + threading = Headache! suggestions welcom
| ||
| Hi, I was working on my project Verlet Max 2D and contrary to my sig, I decided to try out a little threading before I stopped working on it... oops so my question is. can I revive an old thread once it has ended? I tried this by simply using createthread again but it doesnt work right because it takes away the pointer's globalness which is a necessity! Is there a way around this? |
| ||
| Create a thread pool and keep the threads, don't end them, just make them dormant by have them wait for some signal to keep working. |
| ||
| thanks! ok... I tried that using semaphores and now something else is wrong... I guess im on my own with this one because it consists of 1000+ lines of physics and threading code, two of the most misunderstood and/or unexplored areas of game programming. I'll post some simpler example if I find out its a weird bug in bmax threads. |
| ||
| physics is a lot but neither missunderstood nor unexplored, especially not newtonian physics. near indefinitely large systems can be solved. Its more that 95% of the mankind will never be able to understand and use this kind of math to develop such a system. And blitz threads are regular system threads so chances that your design creates dead locks or cross locks is sadly much higher. Source will be good in this case as locks are at best (if at all) possible to be found there. |
| ||
| @Dreamora it is missunderstood by a lot of people that I know... misunderstood as in not understood correctly there are also many unexplored areas of physics... it is one of those areas of programming that will most likely never be completely explored, meaning we will never find EVERY way of calculating physics and you can never stop finding new and uniqu ways of optimizing physics. all in all I guess its mostly an opinion statement what do you mean by dead locks or cross locks? is there an example of how this would happen because after experimenting I have discovered that the verlet update thread is randomly locking itself for no reason. |
| ||
| dead lock / cross lock means that you have 2+ threads that block each other due to incorrect usage of mutex Commonly you should have as few interdependencies as possible. If possible the interdependency is restricted to a single concurrent datastructure that handles the data (for your case this could be pretty simple depending on how you do. A "to process" waiting queue and a "processed" waiting queue, both storing task objects. the physics thread pool then would check the to process queue and get a waiting task or go back to sleep for xxx ms once done, the task would just throw the result into the processed queue for the main thread to use. the importatn thing is that this requires a queue thats thread save so you need to write your own "parallel linked list" or whatever for this task |
| ||
| ok I have figured out what I was doing. My update verlet functions acceses methods wich lock certain mutexes but those methods can also be used by the main thread. I guess this created some sort of lock. |
   |