Ok, I calmed myself down and will create a different approach: imitating arbitrary pause/resume functionality for threads using mutexes and a helper thread. This helper thread permanently locks a number of qmutexes and will release them for a short time with a combined lock/unlock call (the relock I implemented for something though) to resume the thread. How other threads should the helper thread is something I'm working on right on. However, to prevent the exact problem I got with condition variables, I'll now drop the event stuff and introduce a preemptive thread resuming. That means if a thread wants to resume another threads while it's already resumed, a counter will increse and the pause by the thread will be skipped. Using this I can simply tell the tasker to continue a list of threads waiting on an event. And when the waiter thread misses the currently dangerous gap and wants to pause itself, the resume counter will be other than null and no pausing will happen cause it's not necessary. The tasker should also only try to resume if the thread allows preemptive resuming. In the tasker/waiter case, this should only be activated if the waiter thread really already wants to wait on something. Meaning that if there's a finished low-priority tasker increasing the waiter's resume counter, the next waiting will simply not continue due to that.
So that might be a solution. I'm trying. I'm goddamn trying. I knew I used pause and resume in Purebasic a lot. It was very useful and I'm still annoyed about the fact that SDL doesn't have anything like that. Oh man.