Alex Turjan wrote:
Dear Vladimir,
Not really. There is no requirement for "the units
part of the alternatives of a reservation must belong to the
same automaton". Querying should also work in this
case because function cpu_unit_reservation_p checks all
automata for an unit reservation.
Indeed it checks all automata but Im afraid that according to my pipeline
description this check is not enough to guarantee a correct scheduling
decision, e.g.,
suppose the following insn reservation:
(define_reservation "move" "( (unit1_aut1, unit1_aut2) | (*)
(unit2_aut1, unit2_aut2) )
,where unitN_autM refers to unit N from automata M. In this case there are 2 automata.
Now supose a scheduling state S made of the individual states of the two automatons S=<S_aut1,S_aut2>. According to what I see happening in insn-automata.c (and target.dfa), from S_aut1 there is a transition for unit1_aut1 and from S_aut2 there is a transition for unit2_aut2.
It seems that the automata do not communicate with each other. As a consequence,
A scheduling decision which results in the resource reservation
(unit1_aut1, unit2_aut2) would not be rejected, while it should.
In my opinion, the current implementation sees the reservation defined in (*)
As equivalent to the following one
(define_reservation "move" "( (unit1_aut1| unit2_aut1) ,
(unit1_aut2| unit2_aut2) )
Which does not seem true to me.
Is there a way for automatons to communicate so that the alternative
(unit1_aut1, unit2_aut2) would be rejected?
Last two days, I've been working on this issue. I found that you are
right, genautomata permits to generate incorrect automata although I did
not find that it is a case for major current description which I checked.
I found the issue is complicated. Genuatomata has already a check for
correct automata generations in check_regexp_units_distribution but that
is not enough. I am working on formulation of general rules for correct
automata generation and implementation of their check. I think it will
take a week or two to do this and check how does it work for all current
automata description.
Alex, thanks for pointing out this issue to me.
