I was able to identify the bug that caused my tasker/thread manager to take longer than expected. After a rather cumbersome experimentation session I found out that it happens only a tightly timed situation where a thread manager won't be able to notice that a thread got resumed and then immediately paused again. In my situation, this resulted in the tasker not doing a pause at all but actually polling for new tasks until some set it's end condition. Quite hard to track down but I'm glad to say that it finally worked now. Atleast the happening rate changed as I was not able to identify a failed test after the fix. Now, pausing and the resuming threads will both do a second to continue together without any opposite betrayal. Hooray! This is how I like a bugfix reward. Now I only have to fix a problem with the debug system. Not only that I noticed segfaults, I also know that there's atleast another module where a complete program freeze can happen. The only qmutex the whole program uses is the debug qmutex for debug output. Therefore, I definitely know that it either has to do with false use or a general flaw of the debug system. But I'm still wondering whether it was really necessary to create the hash module. The errors are exactly the same and not as fast as before. Therefore, I can of course feel good cause it works as "good" as before, but it also tells me that it was not necessary if it didn't solve the problem... Well, I got a nice hash solution nontheless. I don't give a damn about any different approach than just using module and lists - works fine in every case.
Anyway, today is almost over and I think I've earned a few hours of playing. Good that I sorted this out. I'll do some more tests later with more special and tightly communicating taskers and tasks. Or I could just continue and do some game engine content! Yeah, some nice software rendering for example. I'd enjoy this - especially with my vector/loop macros.