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.
|