Ok, I think I found a bunch of smaller problems and two problems of more systematic nature. One results from the fact that SDL's GetThreadID returns the own thread id when passing NULL. A behaviour which will effectively leads to point where for some reason everything get's deadlocked or something like that. Shortly, I should build a state machine to prevent a non-starting thread from beeing waitable. The other problems comes from the unsurprising disappearance of a local variable which's needed beyong the function calls lifetime. Simply put, eliminating both of theses bugs should actually result in no flawless execution and further testing fun! Right now, I'm very convinced that I've become in analysing my own system with proper debugging messages. Well... I'd prefer to have my message a bit more "sorted" right now - a single stream of, though correctly timed, wildly mixed messages from all threads with no optically distinguishable differenciation except the thread number is a bit nasty to read. Therefore, I'd like to have a layout in which every thread gets his own column in a table. With some nice seperators, it should be way more easy to distinguish threads this way. However, I'd need some sort of clever "hey, detect whether this thread popped up, or isn't there anymore and also just find his column" mechanic to do this properly. You see, I don't want to pass thread-wide debug variables to every function - a criminal approach if you ask me. No, I'll probably create some sort of list and check what thread had which column. I could also use a hash array, so that list flexibility is only required when values look to similar. But darn, that would be a problem if a new thread kicks in. So it HAS to be a list. Anway, the whole debugging output is so damn non-efficient in terms of performance, it won't actually hurt I think. And if I want to use this whole system with custom task content and some more nicely done interfaces, I WILL want a good debug output - you'd want to, too, then!