Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Activating defaults with port or timer parameters

Activating defaults with port or timer parameters 18 Feb 2003 15:11 #6397

Hi,

I would like to discuss the issue of activating defaults with port or timer parameters. Currently, this is disallowed by the standard because a) tiemrs and ports can only be passed by value, and b) only altsteps with no reference parameters may be activated. The latte restriction is there for a good reason: the scope in which the altstep is activated, and the scope in which is is executed, are not necessarily the same. Any reference used during the activation may be void by the time the default is evaluated - using references is "unsafe".

But of course, one can easily come up with some examples why allwing ports and/or timers as parameters to defaults would make sense.

The port case:

By allowing ports to be passed to defaults, it is possible to activate the same altstep as default for different ports. A very simple example is a default that sets a fail verdict whenever a message is received on a specific port:

altstep fail_on_receive(PortType P) {
[] P.receive {
setverdict(fail);
}
}

No, one could think of a situation where this altstep should be activated twice for different ports to handle unwanted communication.

I think that it would make sense to allow activation of fail_on_receive and the activation of altsteps with port parameters in general. And it is not unsafe in the above sense: any port that can be passed to a function/altstep as parameter is necessarily a port of the current component. A component's port lives as long as the component does and hence the reference to the port cannot become void. Thus, I see no reason why it should not be allowed to activate altsteps with port parameters.

The timer case:

Similar examples can be given why it would make sense to activate altsteps with timer parameters, but the problem is that activating altsteps with timer parameters is unsafe:

altstep as(timer T) {
[] T.timeout { setverdict(fail) }
}

function f() {
timer T;
T.start(10.0);
activate(as(T));
return;
}

testcase tc() runs on CompType {

f();
P.receive(?);

}

By the time that T.timeout is evaluated, T (as declared in f) has ceased to exist and the reference is void.

I see three ways solutions to this problem:

1) Disallow activation of altsteps with timer parameters - the safe solution.
2) Allow activation as long as 'component timers', i.e., timers declared as component members, are used to instantiate the parameters - the unclean solution.
3) Allow activation and cause a run time error in case of a void timer reference - the unsafe solution.

I tend to prefer the safe solution.

Once we have come to a sufficiently common understanding of how these things should be handled, I am going to write a CR, but I guess we should discuss this issue first.

Opinions?

Best regards

Stephan Tobies

--
Stephan Tobies Research Engineer, Nokia Research Center
Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin