Peter Firmstone wrote:
Patricia Shanahan wrote:
On 7/5/2010 8:39 PM, Peter Firmstone wrote:
Patricia Shanahan wrote:
Peter Firmstone wrote:
...
This is where you have to be careful of Distributed computing, I
think you'd have to branch out in both directions, checking older and
younger tasks as the tasks arrival may be a combination of processing
remote and local calls. In fact a task might arrive so far out of
sequence that it could be at the opposite end of the queue.
...
So what happens if Task x arrives so late that we have already done
the runAfter tests for Task y, but y should run after x?
Patricia
Hmm, yes I was just thinking that, need to look at the implementations
again...
I've checked both the comments and the code. The TaskManager class
Javadoc comment talks about "not required to run after any of the
tasks that precede it in the queue", and I believe that is the way it
is implemented. For example, takeTask sets the size to i in the
runAfter call for a candidate at index i in the list.
It seems to be the caller's responsibility to make sure that a task
is not added to a TaskManager until after any task it needs to run
after.
Patricia
Hmm, yes you have a point, that is the current behaviour.
It'll be interesting to see if we can simulate RemoteEvent's arriving
out of order with a time delay between them. I suspect that the state
would just get muddled without any complaint, we'd need to test that
with a current implementation, then decide which party should be
responsible.
I'm interested in getting River to run on the Internet, currently
River / Jini is at home on local intranet's where there is probably a
very low likelyhood that RemoteEvents will be received out of order.
I suspect this behaviour was overlooked or missed by the designer, the
caller cannot always know, if it did, I wouldn't need a TaskManager
that manages dependencies, just a fifo queue. But I could be wrong.
It's a pity the original author isn't around to comment. I find my
understanding improves as I implement things, we don't have to know
the right answer up front, so experiment away, I'm confident you'll
work out a good solution, based on your comments to date.
My assumption (and that's all it is) is based on tasks taking sufficient
time, combined with enough queue length and current locking with poor
scalability to allow all RemoteEvents and thus tasks to arrive on the
queue on a low latency network for it not to have been an issue. I
suspect that you'll fix it so well, that the queue will be empty,
waiting on the network and therefore the dependency's won't get checked
at all.
Cheers,
Peter.
