Peter Firmstone wrote:
Peter Firmstone wrote:
Patricia Shanahan wrote: .
Essentially, this is the usual operating system strategy of putting
threads that are not currently runnable in a data structure
associated with the reason for non-runnability, outside the priority
structure that dispatches runnable threads. This minimizes the cost
to the dispatcher of a thread that cannot do anything useful until
some disk read finishes.
Hmm, this shows problem solving experience, take a learning and reapply
it to something new. Would this mean that you'd have a dispatch thread
that checks if the parked tasks are ready?
Be careful though, a task that has been parked might be depended upon by
some other task in the queue, that's what I don't like about the current
implementation, there is no way of knowing that you are checking all
tasks on the queue unless you lock the queue, and then, how do you know
your not dependant on some task that is about to be added to the
TaskManager but is being blocked by holding a lock. Having said that
though, the current implementation seems to work, it needs further
investigation.
As you note below, a sequence number or some other ordering mechanism is the
most common way that is used to order tasks. The task objects are added to the
queue in the order that the sequence number increases, so it's not possible for
an task to appear in the queue until after its dependents (those that execute
before it) are already there.
This type of logic is essential to making this type of thing work.
Gregg
You know, task implementation objects could communicate using a static
atomic integer sequence id, all task objects could use it to determine
if they are ready to execute, if a task has an object sequence number,
equal to the sequence id, then it is ready to execute, if less, it could
throw a sequence exception, if greater, it isn't ready. The same
behaviour could be managed by a Group implementation.
Just an idea, don't know if it is relevant to any implementations.
This approach has its highest cost if the TaskManager has a lot of
tasks, and we are adding a Task depends on none of them but is of a
type that might depends on another Task, so it has to scan the entire
Iterable.
