1.25.2012

Unriddled!

I found and solved the problem. To avoid having a list of dynamical or pool-managed mutex/qmutex allocations inside the thread manager I simply stored right in the thread itself, making the overall implementation a bit simpler but more difficult to use in the end. However, due to thenature of a qmutex, each currently or previously involved qmutex must not be deleted until all threads that may still be in the qmutex query left it. More specific, the problem lies within the per-qmutex linked list data cause every qmutex is also an item in a linked list. And what happens when a linked list entry gets deleted? Right, it cannot be accessed and thus not everything will work out fine. But that is not the actual problem, it's it associated mutex object that will be deinitialized before the thread manager doesn't use it anymore. It's a very fragile system and there's not really a way around to solve it without more system objects (and I'm really using a lot right now). However, keeping these rules in mind and also writing them down so that others may follow them, I can build a more comftable interface doing all this stuff for me. Cause in the end every game or simulation has a fixed number possible threads and one can prepare them in the beginning. So yeah, riddle solved! That makes me happy. And it also means that I can upload it in the current version, add some documentation and have a good example of what and how I'm currently working on it! Good for my internship application. I mean it's an internship after all and no test or run for a job. A good friend was kind enough to mention it to me once again. I tend to forget that and bury myself in unreal expectations about what is expected from me. Nobody can't really expect from a fresh student to already have production-quality experience - that's what a student's internship is for! Anyway, I'm happy that I didn't do anything wrong in the library code but only just used it improperly. Well yeah, that's always the problem with newly created technology: one always has to test out how and where to use it, even it theory and implementation are totally your own. Also, I'll upload some Windows and Linux binaries of the old 3D chess game viewer I was working on for an uni project as well as a small OpenGL graphics demo I did out of a similar reason. Even if both of them are rather not what I'd call proper, they are a good representation of what I usually in limited time and a bunch of more or less complex problems. In fact, the chess game viewer has some pretty non-trivial things in it (the parser to be exact). I didn't cover the concept formally in the source code since it's all very, very chess-specific and time was limited. Well, I think those three are totally enough a long with this rather pathetic Java game for which I did admittedly quite good-looking graphics! Definitely have to say what I did where to not let the spaghetti code or other people get on my account for sure.

No comments: