Am Montag 05 Oktober 2009 13:35:26 schrieb Baxter Jeremy:
I agree, that is why I was not keen on reschedule-until. If blocking is used I think an unexpected deadlock could occur unless all blocked tasks can be resumed in any order, not strictly in reverse order of their reschedule calls as in the current implementation.
this_task::reschedule_until( pred) does inline-execution of tasks -> until pred() returns true the worker-thread tries to dequeue tasks from its local- queue. thus the blocked tasks can not be resumed in any order. inline-execution is used by sub-tasks too.
I think Oliver's intention to use a fiber style scheduler is the right one. To avoid problems all possible mechanisms of blocking would need to be considered and protected against and the temptation would be to declare most tasks as blocking. Even if tasks don't block they may run on the thread for a long time before returning.
yes - version 0.4.0 will use fibers and a user-mode-scheduler. this_task::reschedule_until() is replaced by this_task::block(). the task calling this_task::block() is suspended by the ums and another task will be resumed by the worker-thread (or a new task is dequeue from one of the queues). inline-execution of tasks is only used for sub-tasks.
A dynamic thread pool would also be a solution, starting more threads as tasks block and cleaning them up when the queue is empty. This is the approach used in the Java Executors class (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executors. html). I'm not sure if there is a way to detect the difference between threads being busy and being blocked as in general you would like to keep the number of unblocked threads down to the number of cores.
at a certain amount of worker-threads the performance will be decreased - so spawning additional threads will not allways help. beside of the current static_pool I plan to provide a dynamic_pool (some later releases). regards, Oliver