[
Lists Home |
Date Index |
Thread Index
]
Roger L. Costello wrote:
>
> One of my requirements is to be able to process each lot (and the Pickers
> on the lot) concurrently. The hierarchical approach (as well as the
> approach that mandated a specific order) forced the lots to be processed
> sequentially.
Well, not necessarily. You were using xslt, right? The processing
order is not specified, only the final order in the result tree. XT,
for example (it may be the only one), does parallelize its work and
interleaves it at the end, as I understand it.
> Let me try to give an intuition on why this is so. Consider
> three adjacent lots on the Vineyard, with Pickers on the two outer lots, and
> no Picker on the inner lot. Each Picker concurrently makes its decision
> where to move, based upon local information (i.e., how many ripe grapes are
> in neighboring lots). Suppose that both Pickers elect to move to the inner
> lot (many ripe grapes there). Picker 1 removes itself from the lot that it
> currently resides on and positions itself onto the inner lot. The two lots
> are written to the XSLT result tree. However, Picker 2 is doing the same
> thing. Thus, in the result tree we now have two different versions of the
> inner lot.
Do you meant that there would be an attempt to write the same attribute
twice with different values? But if you had the parallel processing you
say you seek, the same thing would have to happen - both pickers would
assign themselves to the same lot since there would have been no
sequencing to prevent it. And the result would have been the same.
To capture the result, you could not use an attribute, you would need an
element structure. But if the problem was not a multivalue attribute
then I don't see what the problem was at all.
> The only way that I could see how to do it was to first process
> Picker 1, then process Picker 2 using the state that resulted after
> processing Picker 1, i.e., process the lots/Pickers sequentially. I hope
> that I made some sense in this description.
>
Wait a bit, something does not add up here. Given what I said just
above, you should have _wanted_ to have two pickers on the same lot.
Now you say you had to prevent it.
You are really thinking about a society of agents here, are you not?
The agents have to communicate and negotiate in a case like this, so who
cares if you had a collision on one step? It would need to be resolved
either way.
In xslt, that would be done with a separate template to resolve the
collision, to be invoked instead of the normal template handling that match.
Cheers,
Tom P
|
