Title Solve component coordination problem
Priority meta Status chatting
Superseder Nosy List florian, jendrik, malte, silvan
Assigned To Keywords
Optional summary

Created on 2015-07-21.15:02:48 by silvan, last changed by malte.

msg5122 (view) Author: malte Date: 2016-01-20.15:59:33
It's not about initialization: it's about what happens if two searches use the
same heuristic concurrently and hence share path-dependent information.
msg5121 (view) Author: florian Date: 2016-01-20.15:56:41
This also affects how path dependent heuristics should be initialized (see msg5120).
msg4419 (view) Author: silvan Date: 2015-07-21.15:02:48
A "component" in the sense of this issue is an object that can be created by the
user on the command line, such as an FF heuristic, a merge strategy, a landmark
factory or a search algorithm. Currently, we have two kinds of components: ones
that can be assigned to a variable (e.g. landmark factories, heuristics) and
ones that cannot (e.g. merge strategies). One question is whether we want to get
rid of this distinction. Currently it serves a purpose because some of our
components cannot work when used in two contexts at the same time, and not being
able to assign them to variables prevents them from being used in two contexts.

One of the general problems in planner architecture that we still have to solve
is: how do we ensure that different components of the planner fit together
properly. For example, a search algorithm and a heuristic somehow need to be
able to exchange information about the task (the search algorithm must tell the
heuristic which state to consider, and the heuristic must tell the search
algorithm the set of preferred operators), but they might both be working on
different task objects. We have partially solved this by thinking of "task
transformations" instead of tasks, but this is still rather half-baked.

There are also issues related to using the same component in two different
contexts without having interference due to its attributes. For example, if we
want to use the same landmark graph in two heuristics, I think this would
currently cause problems because there is information about ongoing computations
stored within the landmark graph object. (This could be resolved, for example,
by making sure that something like this never happens -- e.g. by making all
references to other components const.)

For now, we don't really have a good idea how to address this. The main purpose
of this issue is to have a reference point that we can use to annotate parts of
the code that relate to this issue. When working on this issue, we should make
sure to search the code comments for references to this issue number.
Date User Action Args
2016-01-20 15:59:33maltesetmessages: + msg5122
2016-01-20 15:56:41floriansetmessages: + msg5121
2015-07-22 01:36:49floriansetnosy: + florian
2015-07-21 20:48:16jendriksetnosy: + jendrik
2015-07-21 15:02:48silvancreate