Issue661

Title retrieve mutex group numbers from AbstractTask
Priority feature Status resolved
Superseder Nosy List florian, jendrik, malte
Assigned To Keywords
Optional summary
Since mutexes are currently only used in the landmarks code, this issue is on 
hold until issue551 is merged.

Created on 2016-07-05.16:20:25 by jendrik, last changed by jendrik.

Summary
Since mutexes are currently only used in the landmarks code, this issue is on 
hold until issue551 is merged.
Messages
msg10196 (view) Author: jendrik Date: 2021-03-18.14:28:45
I don't think we plan to pursue this, so I'm closing the issue.
msg5476 (view) Author: malte Date: 2016-07-06.02:04:50
I have some concerns:

1. I support the desire for efficiency, but the interface must also be
reasonable to use on a semantic level, i.e., ideally translate directly to
concepts that people will know from reading research papers. The whole notion of
"mutex groups" is currently an implementation detail that should not bleed into
user code in this fashion, or at least not until we've thought about alternative
ideas.

2. Returning a vector by reference means that this information always needs to
be materialized somewhere, which clashes badly with the design goals of the task
interface. This looks like an absolute no-no to me. I don't see how this could
be reasonably implemented without completely breaking the current design.

3. More technically, I guess you meant "const vector<int> &", not "vector<int>
&". The user should not modify the task by adding mutexes in this fashion.


Suggestion: let us collect the current and planned uses of mutexes in the code
and then design a new interface based on this. (I don't understand what you mean
with with "two sets of facts being mutex", so I'm not sure what the current
dominant access pattern is.)

I'd be strongly against completely getting rid of high-level methods like
"are_mutex" unless there are adequate (high-level) replacements. Hopefully we
can come up with an interface that is both sufficiently high level and
efficient. Perhaps this means that "mutex groups" continue to remain under the
hood, used by new high-level methods, and perhaps they should be evalated to a
user-visible concept. But as with all new interfaces, we should design this
carefully.
msg5475 (view) Author: jendrik Date: 2016-07-05.16:20:25
While working on issue576 we noticed that we need a way to retrieve the combined mutex 
information of a task from AbstractTask. Currently, AbstractTask only supports querying 
whether two given facts are mutex. When inspecting where and how mutexes are currently 
used, we noticed that the code actually wants to test whether two *sets* of facts are 
mutex. In order to solve both issues efficiently, we propose to store the mutex group IDs 
of each fact and use the following interface:

vector<int> &AbstractTask::get_fact_mutex_group_ids(const FactPair &fact) const;

vector<int> &FactProxy::get_mutex_group_ids() const;

Especially the latter resulting reference mustn't outlive the called FactProxy object. It 
remains to be seen whether we still want to support the old FactProxy::is_mutex(const 
FactProxy &other) interface.
History
Date User Action Args
2021-03-18 14:28:46jendriksetstatus: chatting -> resolved
messages: + msg10196
2016-07-06 02:04:50maltesetstatus: unread -> chatting
messages: + msg5476
2016-07-05 16:21:20jendriksetsummary: Since mutexes are currently only used in the landmarks code, this issue is on hold until issue551 is merged.
2016-07-05 16:20:25jendrikcreate