Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

End to end flow instantiation broken for flows through threads #1953

Closed
lwrage opened this issue Aug 19, 2019 · 11 comments
Closed

End to end flow instantiation broken for flows through threads #1953

lwrage opened this issue Aug 19, 2019 · 11 comments

Comments

@lwrage
Copy link
Contributor

@lwrage lwrage commented Aug 19, 2019

Summary

Flow implementations in threads can go through subprogram calls in this case end to end flow instantiation fails because connection instances end at the thread.

Expected and Current Behavior

Flow implementations in threads should take only the end points into account everything else should be ignored.

Environment

  • OSATE Version: 2.5.1
  • Operating System: all
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 30, 2019

Example from Lutz:

package test
public
    
    process top
    end top;
    
    process implementation top.i
        subcomponents
            t0: thread th.i;
            t1: thread th.i;
            t2: thread th.i;
        connections
            c1: port t0.op -> t1.pip;
            c2: port t1.pop -> t2.ip;
        flows
            e2e: end to end flow t0.src -> c1 -> t1.pth -> c2 -> t2.snk;
    end top.i;
    
    thread th
        features
            ip: in data port;
            op: out data port;
            pip: in data port;
            pop: out data port;
        flows
            src: flow source op;
            pth: flow path pip -> pop;
            snk: flow sink ip;
    end th;
    
    thread implementation th.i
        subcomponents
            s1: subprogram s1;
        calls
            cs1: {
                call1: subprogram s1;
            };
        connections
            ct1: parameter pip -> call1.p1;
            ct2: parameter call1.p2 -> pop;
--        flows
--            pth: flow path pip -> ct1 -> s1.s1flow -> ct2 -> pop;    
    end th.i;
    
    subprogram s1
        features
            p1: in parameter;
            p2: out parameter;
        flows
            s1Flow: flow path p1 -> p2;
    end s1;
end test;

He says

if you remove the comments on the flow impl in th.i, the flow is no longer instantiated. Note that a flow impl in a thread that goes directly from an in port to an out port should not be ignored.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 30, 2019

Currently, the end to end flow instance is created correctly if th.i has the trivial flow implementation

            pth: flow path pip -> pop;  

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 30, 2019

I'm confused what is the desired outcome here? Should the generated end to end flow

  1. contain entries for the subprogram, etc., or
  2. be identical to the trivial case, merely passing through the thread component?

@lwrage
Copy link
Contributor Author

@lwrage lwrage commented Aug 31, 2019

It's option 2. Trivial flow implementations through threads should be interpreted if present. (This is needed because the flow spec could be between two feature groups whereas the corresponding flow implementation could select a specific feature in that feature group.) All other flow implementations in threads should be ignored.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 3, 2019

Okay, based on conversation with Lutz, what is desired is that if the flow implementation is simple, it should be used. This is account for connections between port groups. But any flow implementation that goes though a subcomponent (really, a subprogram call) of the thread should be outright ignored.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 10, 2019

Okay, cooked up two test packages

package SimpleConnections
public
    subprogram sub
        features
            p1: in parameter;
            p2: out parameter;
        flows
            subPath: flow path p1 -> p2;
    end sub;
    
    thread th
    	features
    		ip: in data port;
    		op: out data port;
    	flows
    		fpath: flow path ip -> op;
    end th;
    
    thread implementation th.simple
	   	flows
    		fpath: flow path ip -> op;
    end th.simple;
    
    thread implementation th.withCall
    	subcomponents
    		sub1: subprogram sub;
    	calls
    		normal:{
    			call1: subprogram sub1;
    		};
    	connections
    		c1: parameter ip -> call1.p1;
    		c2: parameter call1.p2 -> op;
   		flows
    		fpath: flow path ip -> c1 -> sub1.subPath -> c2 -> op;
    end th.withCall;
    
    thread th2
    	features
    		ip2: in data port;
    		op2: out data port;
    	flows
    		fsrc: flow source op2;
    		fsnk: flow sink ip2;
    end th2;
    
    thread implementation th2.i
    	-- trivial
    end th2.i;
    
    process top
    end top;
    
    process implementation top.generic
    	subcomponents
    		t: thread th;
    		q: thread th2.i;
    	connections
            c1: port q.op2 -> t.ip;
            c2: port t.op -> q.ip2;
        flows
            e2e: end to end flow q.fsrc -> c1 -> t.fpath -> c2 -> q.fsnk;
    end top.generic;
    
    process implementation top.simple extends top.generic
        subcomponents
            t: refined to thread th.simple;
    end top.simple;
    
    process implementation top.withCall extends top.generic
        subcomponents
            t: refined to thread th.withCall;
    end top.withCall;
end SimpleConnections;

and

package FGConnections
public
    feature group FG
    	features
	    	x_in1: in data port;
	    	x_in2: in data port;
	    	x_out1: out data port;
	    	x_out2: out data port;
    end FG;

	feature group FG_inverse inverse of FG
	end FG_inverse;

    subprogram sub
        features
            p1: in parameter;
            p2: out parameter;
        flows
            subPath: flow path p1 -> p2;
    end sub;
    
    thread th
    	features
    		fg1: feature group FG;
    		fg2: feature group FG_inverse;
    	flows
    		fpath: flow path fg1 -> fg2;
    end th;
    
    thread implementation th.simple
    end th.simple;
    
    thread implementation th.specific
    	flows
    		fpath: flow path fg1.x_in1 -> fg2.x_in2;
    end th.specific;
    
    thread implementation th.withCall
    	subcomponents
    		sub1: subprogram sub;
    	calls
    		normal: {
    			call1: subprogram sub1;
    		};
    	connections
    		c1: parameter fg1.x_in1 -> call1.p1;
    		c2: parameter call1.p2 -> fg2.x_in2;
   		flows
    		fpath: flow path fg1.x_in1 -> c1 -> sub1.subPath -> c2 -> fg2.x_in2;
    end th.withCall;
    
    thread th2
    	features
    		fg1: feature group FG_inverse;
    		fg2: feature group FG;
    	flows
    		fsrc: flow source fg1;
    		fsnk: flow sink fg2;
    end th2;
    
    thread implementation th2.i
    	-- trivial
    end th2.i;
    
    process top
    end top;
    
    process implementation top.generic
        subcomponents
            t: thread th;
            q: thread th2.i;
        connections
            c1: feature group q.fg1 <-> t.fg1;
            c2: feature group t.fg2 <-> q.fg2;
        flows
            e2e: end to end flow q.fsrc -> c1 -> t.fpath -> c2 -> q.fsnk;
    end top.generic;
    
    process implementation top.simple extends top.generic
        subcomponents
            t: refined to thread th.simple;
    end top.simple;

    process implementation top.specific extends top.generic
        subcomponents
            t: refined to thread th.specific;
    end top.specific;

    process implementation top.withCall extends top.generic
        subcomponents
            t: refined to thread th.withCall;
    end top.withCall;
end FGConnections;
  • Instantiating SimpleConnections::top.simple should generate the end to end flow instance.
  • Instantiating SimpleConnections::top.withCall should not generate the end to end flow instance.
  • Instantiating FGConnections::top.simple should generate four end to end flow instances.
  • Instantiating FGConnections::top.specific should generate one end to end flow instance.
  • Instantiating FGConnections::top.withCall should not generate the end to end flow instance.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 10, 2019

Not sure there is anything to do for this issue, other than verify that things are doing what we want. According to the above tests, everything already does what we want.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 10, 2019

Added JUnit test.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 11, 2019

Okay, was still confused about this. What we want is if the flow implementation of the thread contains a path through subprogram calls, the corresponding flow specification should be used instead of the flow implementation during the creation of the end to end flow.

Because Thread components can only have data and subprogram subcomponents, I think it is okay just to test if the flow implementation based on length:

  • flow source and flow sink implementations should have a length of 1
  • flow path implementations should have a length of 2

(Didn't really consider flow source and sink in the previously discussion/examples. Need to update the examples for them.)

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 13, 2019

Full testing of flow sources is broken because of Issue #1987.

Follow up: Not entirely true. The declarative model has errors on the flow source. declaration due to #1987, but the generation of the instance model works just fine.

AaronGreenhouse pushed a commit that referenced this issue Sep 13, 2019
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 17, 2019

Fixed CreateEndToEndFlowSwitch.processSubcomponentFlow(ComponentInstance, EndToEndFlowInstance, FlowSpecification, FlowIterator).

Need to update/create JUnit tests.

@lwrage lwrage closed this Sep 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants