12.06.2012

No post title

Hooray! Finally some content on this blog related to programming. I've been working on my multithreading system for quite some time now and I was able to almost completely elimited all polling mechanic, complex thread linking operations and whatever else ugly was left. What I'm currently going for is an almost pure message passing and event based approach to communicate between threads. I had many fallbacks to the previous version but only now I got the essence of what makes message passing so awesome: it's strictness. Messages exist between two threads, there is no concurrency except when on message box access as multiple threads can send to one message box of one thread. However, it contradicts with my idea of creating a job/task system where any thread can wait for any job or task to be done. Both systems have their advantages and disadvantages but I prefer the message passing way cause it's simple, effective and clean compared to the other one. I encountered a bunch of problems on my way to still support random waiting on tasks loading and releasing resources. One way is to have each thread send their jobs/tasks to the worker thread/tasker and let the tasks only do work if the resource has not yet been loaded/released. Before scheduling a task, it'll check whether the resource is loaded or not, too. This ensure that already loaded resource won't be in schedule if it got loaded before but what about multiple threads sending their tasks all together waiting for one resource? One task will finish the job and the others cycle through until every thread got it's signal. But what if there's another huge resource right after the first task execution? The desired will already be loaded but the waiting threads will have to wait for the second resource though they could already continue their work. On a second thought... I'm using a single event to message ALL waiting threads so that can check their task's execution status. If I could somehow add a custom code to be called between... Well, this would make it possible to not only check for a task status but also for a resource status. Hmmm, I just need split the interface like I did before... Anyway, you see that there are always annoying bits to care about. I'm close to an optimal solution in terms of simplicity and efficiency merging. This'll be some good bachelor thesis result I think. All the time I'm getting a new idea it's based on just one idea I used to realize events with my qmutex construct. It's based on four functions calls in a row you can dynamically change in execution logic with some boolen triggers passed as params. The result can be a simple mutex, a query of waiting threads or a combinations of both depending on what code you do inbetween. I really love the concept but I find it hard to fully utilize cause I underestimate it's potential all the time. It's exactly what one needs if there's a complicated tradeoff to make between performance and complexity in terms of multithreading synchronization. Guess this is some sort of pioneer wor I got myself into. Darn. That's always the most annoying if you try to fully optimize something.

No comments: