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.
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.
