I found a massive problem while designing the new event system that may be the reason why SDL's condition variable didn't work for me. If that is case, I was more than wrong and shouldn't blame anyone but me. The point is that my toggle object, signaling on true or false or a change of these states, had a gap in it's logic which would effectively prevent a waiting thread from catching his signal. I wasn't to notice that before cause it worked fine in my test. But now I see the real problem and have to reorientate. The good thing about it is, that if SDL's broadcast function really, really actually works, I won't need to rewrite my current tasker system (which I prefer over the other I designed after the last blog post). And now I'm really asking myself how to solve this. The real problem I have right now is that a signal send by a condition variable has exactly the same problem as my own qmutex/event implementation: a sent signal will be lost if it's appropriate receiver started waiting too late. A naive approach would be to use a mutex to lock the event one would wait for, blocking the sending thread from sending the signal too early. However, this would simply block the sending thread and nothing could ever work. So I'll have to say the thread that he should simply only start signaling after it's waiter started waiting. Which is totally impossible with only threads cause after starting the process, now signal can be initiated by this thread. It's such a fucking stupid problem, seriously. There's no real feedback in SDL for whether a thread went waiting, nor is there any way to poll it. Fucking stupid. The only thing I can think of is to use polling and a signal buffer. I can't really use the waiting on a mutex or condition variable cause I still need to shoot the event after intiating the waiting, which's once again no possible when waiting. Even if you could manage to have a third thread waiting a short time to let the waiter start waiting and then shooting the event, you'll still need some sort of delay or a function to fucking wait for a thread status change!

Who in hell did design something so incredibly useless? All just based on fucking mutexes! I had so much trouble to find this out and now it seems all totally useless and wasted. You know what, it's done for this weekend. I don't wanna hear or write or code something about until monday. I'm pissed and off. Stupid multithreading.

No comments: