Peter Firmstone wrote:
Patricia Shanahan wrote:
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?
We always know when a Task finishes or is removed. At that point, ask
"Does this Task have any others that have reported dependency on it?".
If so, for each of those tasks, do a new dependency check. If there
are now no dependencies, put is in the dispatch data structure. If
there is at least one dependency, attach it to the task on which it is
now known to depend and reconsider it when that task finishes or is
removed.
Patricia
Interesting.
net.jini.lookup.ServiceDiscoveryManager contains several classes that
implement Task and use sequencing.
I found 54 subtypes of Task in Apache River, doing a quick search.
I know. I've been looking at the Eclipse class hierarchy for
TaskManager.Task, but I've not finished looking at all the TaskManager uses.
Is there some package where it is appropriate to put temporary
experimental code? I'm thinking of creating a NewTaskManager class. I'll
base its initial code on TaskManager. That way, callers can be modified
to use an updated Task interface one at a time. I'll globally rename
NewTaskManager to TaskManager after I've got them all updated.
Patricia
