Peter Firmstone wrote:
So it would seem that the runAfter() method is superfluous and
unnecessary in most, if not all cases? Especially if the caller is
making the decision about when tasks are placed on the queue.
We do need to confirm that in our current implementations, the callers
are taking responsibility for the queue placement. Then try to
discovery why we needed to have a dependency check by the TaskManager.
It sounds like for absolute concurrency the design needs to be totally
revised, perhaps the responsibility of determining if the Task is ready
to be executed should be placed solely on the Task implementation
itself, but not by passing in the list of all Tasks on the queue, but
with a simple:
Do you have a lot of bug reports indicating the concurrency design is
basically broken?
In a few months, when I have had time to learn my way around both the
specification and the implementation, I would be happy to participate in
a liveness and ordering review. I've never done it for software, but
some of the intellectual tools used for proving memory order properties
in large multiprocessor designs were borrowed from distributed software
engineering.
I am opposed to moving the queuing and run after organization work from
TaskManager to its callers. It is work that has to be done, and the
choice is between doing it in one class, or doing it in each class that
needs to both permit some parallelism and yet maintain some ordering
among tasks. It is far less work to make it both efficient and correct
if it only needs to be done in one class.
Patricia
