Subject: Re: [boost] [task] reschedule_until
Date: 2009-10-05 14:14:16
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
> 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).