Out of something completely random, I think I found a solution to somehow rescue my ressource manager model. In essence, I'd only need to move the priorizing of tasks into the tasker thread. This way there wouldn't be a problem with wanting differnet priorities for different tasks from different threads. Anyway, the question is only how and when to actually process these priority changes. The point is that when all threads want to randomly change task priorities without properly synchronizing with the task (which would mean a lot of wasted time), they'll eventually end up with a chain of mutexes yielding the same waiting as waiting on the tasker to frequently give racing conditions for a short time and then letting all other threads wait again. So one solution would be to let the other threads dump priority change request in some memory in the tasker. When all threads start doing this, there is only the question in what order the priorities will be changed. Between taking tasks, a tasker would have to apply these priority changes (if there would be any) to know what to do next. Whether the the rather quick re-priorization occurs in the tasker or in the threads is totally irrelevant since the waiting during the loading process is the real time spend doing nothing. Many, many threads wanting to edit a task list at once won't do themselfs a favor when fighting over who will be next - in the end they send their wish once and another one will evaluate them in the order they came in - exactly the same result, less hurdles with synchronization and better control. I'd need to find a way of getting the memory for these re-priorization list items. It was one thing for tasks cause their memory is fixed and a thread would simply need to wait for one of those tasks to finish (it'd be possible to use the same condition variable for multiple threads, so one would get notification for whatever task would be finished). Priorizing is fire and forget. You don't worry about it because so many can alter the priority that you can't predict that exactly the wanted priorization kicked in. Using a fancy system for putting the wished priorization into the task itself is also no option cause the tasker only knows the top and the bottom task in it's list, so it's the easiest way to simply use a list of priority changes with an item for each task to change. Well, actually if I put the item into the task (optionally of course, up to the user), I could take a list start in the tasker and have the tasker in only one priorization list... sounds good enough! Yeah, this could work. Let's test it.

No comments: