1.06.2012

Let's continue multithreaded debugging

I spend the last 8 hours or so finding a good and actually working solution for my multithreaded debugging and succeeded so. It was a bit tricky but now that it's done and working, I already have found out some very interesting things isolating the reason why everything freezes from time to time. It happens when two or more threads wait on a ressource to become loaded for the same time: the thread that started waiting in the first place will be able to catch the task completition signal, all others won't continue, stopping the whole problems. There must be some sort of deadlock, waiting on a deleted ressource or just a missed conditiona variable boradcast. The last isn't possible as I already proved this behaviour to never happen with the current code. A deadlock is unlikely cause both threads clearly enter the part function waiting on a condition variable to fire. A deleted object is quite likely because I noticed occasional segfaults when deactivating all debug messages except in main, the threads and load/release functions. Why this only happens with deactivated debug messages is not quite clear. On one side, all each debug output will triggers it's own series of locks and unlocks, possibly changing the thread switching order and preventing the segfault from happening. Also, debugging adds some more mutex/qmutex objects that be stored for each program in a way that accessing a release mutex object will result in it just not beeing deleted but reused until the program closer. Though this is really quite far-fetched I have to admit. So since I've seen this segfault, I definitely know that I have to check for objects becoming released to early and I guess this happens because of the first thread beeing ended. I'm de-initializing a qmutex and a mutex there, so this might be the actual program of it. Let's test it!

No comments: