1.07.2012

Custom condition variable

This morning I had a phenomenally clear head and realized that I can the same effect of a condition variable by using my almighty qmutex construct! Since a qmutex always guarantees that everything will be in order and only at once, I can define an event sender locking it's qmutex by default and several receivers that try to lock this qmutex if they want to wait on an event. And now comes the part where it gets so similar to a condition variable: when sending an event, the event sender will at first write some event information and unlock it's qmutex. the event access will be passed from the first waiting thread to the next one while every receiver will copy the event data before passing. If it's the event he wants, he doesn't need to re-lock the qmutex anymore and is done waiting. But if it's not the event he's been waiting for, he can simply lock back in while all the other wait on it. The event sender will generally always lock the qmutex cause he wants to have control over the whole setup and maybe shoot another even later. Sooooo, it's in essence the same as a condition but more automated and ordered thatn SDL's condition variable. There are of course some spots where I'd say that it depends on whether the event receiver was quick enough for a re-locking so that he will definitely catch the next event. This can be done by locking a "wait, I still need to re-lock!" qmutex activated before unlocking the qmutex in a sender. The master will then try to lock/unlock this qmutex to ensure that. So there'd two queries working with each other to ensure that everything occurs in the right oder. But that's a lot of performance loss with so many lock/unlock and list edits, even if it's multithreaded... Ah, fuck that, I can put this into the qmutex itself! There should effectively no problem combining the lock and unlock operation. I already have an idea how to do this smartly, so I'm gonna get my own condition variable this way! I didn't expect this to be the background of a condition variable to be honest. I mean it's then totally possible with mutexes and I do now see how they must've been out of mutexes. But my version will work then, so that I can rely on it much more and guarantee that it'll work, no matter what stupid operating system wants to come in my way. I can make my own event system with this, my own fully multithreaded feature set. I always dreamed of something like that, having an awesome toolkit I can totally and always rely on. And fuck yes, if this all works out I can friggin say that!

No comments: