| Advanced TTCN-3 usage: busy wait vs. non-busy wait in altsteps [message #1737077] |
Tue, 05 July 2016 14:14 |
 Kristof Szabados
Messages: 60
Registered: July 2015 |
Member |
|
|
One of the worst performance problems in TTCN-3 are caused by busy waiting.
These are bad as busy wait looks very innocent in the code, but drains all computational resources, where there is actually no need for it.
The following 2 example testcases will do the exact same functionality (waiting for an incoming message), with very different performance profile:
private function f_functionName( )
runs on altstepExample_CT
{
timer TL_t1 := 15.0;
TL_t1.start;
TL_t1.timeout;
portname_PT.send( 5 );
}
// demonstrates busy wait
private testcase tc_busyWait()
runs on altstepExample_CT
system altstepExample_CT
{
var altstepExample_CT vl_ptc := altstepExample_CT.create;
connect(self:portname_PT, vl_ptc:portname_PT);
vl_ptc.start( f_functionName() );
alt {
[] portname_PT.receive(integer:*) {}
[else] {
repeat;
}
}
disconnect(self:portname_PT, vl_ptc:portname_PT);
vl_ptc.stop;
}
// demonstrates non-busy waiting
private testcase tc_non_busyWait()
runs on altstepExample_CT
system altstepExample_CT
{
var altstepExample_CT vl_ptc := altstepExample_CT.create;
connect(self:portname_PT, vl_ptc:portname_PT);
vl_ptc.start( f_functionName() );
alt {
[] portname_PT.receive(integer:*) {}
}
disconnect(self:portname_PT, vl_ptc:portname_PT);
vl_ptc.stop;
}
When executed tc_non_busyWait will just wait 15 seconds for an incoming message, without using any processor power.
tc_busyWait will also just wait 15 seconds for an incoming message, but during that 15 seconds one computational core on the executing machine will experience 100% load (and the users an unresponsive machine )
The problem comes from using the repeat statement in the else part of an alt statement.
The else branch is executed whenever the other alt branches can not, and the repeat statement forces the re-evaluation of all of the alt branches.
In effect this structure creates a loop, that can only be broken when one of the alt branches can be executed.
And no matter how cheap the snapshot evaluation mechanism is ... it will be forced to re-execute as soon as it finishes, overloading the machine.
In comparison tc_non_busyWait will just silently wait until a message arrives on the connected port, and do the evaluation only then.
Simple and efficient.
|
|
|
Powered by
FUDForum. Page generated in 0.57339 seconds
] 
Search
Help
Register
Login
Home
