1.07.2012

Multidimensional bug hunting

I was wrong about my previous assumption that I actually proved the condition variable to function correctly. I tested with two threads but not with three! In my testing scenario I used one thread for signaling and another for waiting on the signal. Then I changed the direction and test was done. But what about two threads waiting on it? I build exactly such a scenario and when using SDL_CondBroadcast I got the same effect as when using SDL_CondSignal. The difference between those is that broadcast messages all waiting threads and signal only one. And I'm close to believing that broadcast doesn't function correctly in SDL. However, I also made the mistake of not locking the mutex before waiting, though this didn't change anything. According to this page I found, condition variables are used totally differently. From watching as their code I'd either say they simply didn't label their variables correctly or that condition variables need to be used completely different. I mean look at this code! To work in the expected way, they'd need to start B after thread A. Anway, this is pretty much like my toggle module functions but the fact it does just not work for multiple threads is pissing me more than off. I mean I didn't create all this stuff just to end here because SDL can't do this. There must be something wrong in own use of this mechanic. I fear that I'll need to something for this on my own, that my whole concept won't work anymore with this functionality. I don't know. Maybe it's something so trivial it's too hard to notice for me right now. Wouldn't be the first time happening, but I highly doubt that for obvious reasons. Even if I copy the code they provided and use exactly this way, it will simply not work, I tested it just a few minutes ago. The mutex passed will keep beeing locked the whole time and block any other attempts to signal the waiting threads. It's simply totally dumb. Hm, I'm having any idea. If this wiki states that the mutex be locked and then unlocked by the function while the signal wasn't sent (it worked for me without, too), then it might be the opposite: the mutex will be locked from outside and the thread will wait until it's unlocked and then lock it. But it's the same as I'm doing right now, so I'm stuck again. Stupid false statements. Oh, wait. They use SDL_CondSignal in there, not the broadcast variant. Still, wouldn't broadcast have the same base? Wouldn't broadcast be compatible with waiting, just not taking only a single waiting thread but all in the list? It should, but I don't see that it is working in the way it should work. Whatever fortifies my opinion even further is this helpful article explaining more detailed what a condition variable is meant to be. From what I understood is that the concept is that threads will pass control to each other using mutices. So if I can't rely on broadcast to work, I'll need to make my own. And cause my toggle object thingie is the only using condition variables, I only need to make it work somehow and don't need to find bugs that actually only exist in SDL itself.

Anyway, I won't do this today. It took me the whole day to get the debugging right and analyzing this specific SDL problem so that I don't have the energy anymore. I don't know how exactly I want to realize it. Maybe without the signal functionality (guess I'll definitely need it) or I'm trying to play some tennis with mutexes to possibly wasting some more time upon realising that it may not be possible without signals. Anyway, I'd prefer creating my own version of this just because I can and because I don't want to depend on something that's not implemented correctly. They could be honest and say it doesn't work, but no, they pretend it does. Maybe it works for others, who knows. It certainly doesn't work for right now. I mean what can I else do than exactly what's portrayed there with no success. I know it works for one, but I'm getting tired of fixing stuff up that's not my problem. I can imagine making my own event-shooting system based on one or two seperate threads giving control to other waiting threads in a bit more complex system. Would be definitely less performant than direct, builtin system functions but I can't stand using something which's ensured functionality vanishes depending on the library or the system. I can assume that mutexes will work on every system, so I'll rely on it. If condition variable would work as expected, there wouldn't be any reason to build a qmutex cause I can get the same effect with condition variables.

Oh and the weird reason why I got no segfaults with debug on was cause the expression I used a debug message parameter disappeared together with the debug message of which it was an expression of. So an operation was not executed when it should've been, explaining the segfault. Now it "only" freezes due to the mentioned condition variable problem. And I just had to create multithread debugging functionality. I'd called it a cheap victory if it weren't so sad.

So I'm once again going back to creating the atoms of atoms... The whole operating system and library world simply stinks today.

No comments: