Instance Synchronization
System Testing for C
The RENDEZVOUS statement, provides a way to synchronize Virtual Testers to each instance.
When a scenario is executed, the RENDEZVOUS instruction stops the execution until all Virtual Testers sharing this synchronization point (the identifier) have reached this statement.
When all Virtual Testers have met the rendezvous, the scenario resumes.
SCENARIO first_scenario
FAMILY nominal
-- Synchronization point shared by both Instances
RENDEZVOUS sync01
INSTANCE JUPITER:
RENDEZVOUS sync02
. . .
END INSTANCE
INSTANCE SATURN:
RENDEZVOUS sync02
. . .
END INSTANCE
END SCENARIO
Synchronization can be shared with other parts of the test bench such as in-house Virtual Testers, specific feature , and so on. This can be done easily by linking these pieces with the current Target Deployment Port.
Then, to define a synchronization point, you must make a call to the following function:
atl_rdv("sync01");
This synchronization point matches the following instruction used in a test script:
RENDEZVOUS sync01
Example
The following test script is based on the example developed in the Event Management section. The script provides an example of the usefulness of instances for describing several applications in a same test script.
HEADER "SystemTest Instance-including Scenario Example", "1.0", ""
DECLARE_INSTANCE JUPITER, SATURN
COMMTYPE appl_comm IS appl_id_t
MESSAGE message_t: message, data, my_ack, neg_ack
CHANNEL appl_comm: appl_ch
#appl_id_t id;
#int errcode;
PROCSEND message_t: msg ON appl_comm: id
CALL mbx_send_message( &id, &msg ) @ err_ok
END PROCSEND
CALLBACK message_t: msg ON appl_comm: id
CALL mbx_get_message ( &id, &msg, 0 ) @@ errcode
MESSAGE_DATE
IF ( errcode == err_empty ) THEN
NO_MESSAGE
END IF
IF ( errcode != err_ok ) THEN
ERROR
END IF
END CALLBACK
SCENARIO first_scenario
FAMILY nominal
COMMENT Initialize, register, send data
COMMENT wait acknowledgement, unregister and release
CALL mbx_init(&id) @ err_ok @ errcode
ADD_ID(appl_ch,id)
INSTANCE JUPITER:
VAR id.applname, INIT="JUPITER"
END INSTANCE
INSTANCE SATURN:
VAR id.applname, INIT="SATURN"
END INSTANCE
CALL mbx_register(&id) @ err_ok @ errcode
COMMENT Synchronization of both instances
RENDEZVOUS start_RDV
INSTANCE JUPITER:
VAR message, INIT={type=>DATA,num=>id.s_id,
& applname=>"SATURN",
& userdata=>"Hello Saturn!"}
SEND( message , appl_ch )
DEF_MESSAGE my_ack, EV={type=>ACK}
WAITTIL (MATCHING(my_ack), WTIME==300)
DEF_MESSAGE data, EV={type=>DATA}
WAITTIL (MATCHING(data), WTIME==1000)
END INSTANCE
INSTANCE SATURN:
DEF_MESSAGE data, EV={type=>DATA}
WAITTIL (MATCHING(data), WTIME==1000)
VAR message, INIT={type=>DATA,num=>id.s_id,
& applname=>"JUPITER",
& userdata=>"Fine, Jupiter!"}
SEND( message , appl_ch )
DEF_MESSAGE my_ack, EV={type=>ACK}
WAITTIL (MATCHING(my_ack), WTIME==300)
END INSTANCE
CALL mbx_unregister(&id) @ err_ok @ errcode
CLEAR_ID(appl_ch)
CALL mbx_end(&id) @ err_ok @ errcode
COMMENT Termination Synchronization
RENDEZVOUS term_RDV
END SCENARIO
The scenario describes the behavior of two applications (JUPITER and SATURN) exchanging messages by using a communications stack.
Some needed resources are allocated and a connection is established with the communication stack (mbx_init). This connection is made known by the Virtual Tester with the ADD_ID instruction. Note that this is a common part to both instances.
Then, the two applications register (mbx_register) onto the stack by giving their application name (JUPITER or SATURN). These operations are specific to each instance, which is why these operations are done in two separate instance blocks.
The application JUPITER sends the message "Hello Saturn!" to the SATURN application (through the communication stack) which is supposed to have set itself in a message waiting state (WAITTIL (MATCHING(data), ...) ).
Once the message has been sent, JUPITER waits for an acknowledgment from the communication stack (WAITTIL(my_ack),...). Then, it waits for the response of SATURN (WAITTIL (MATCHING(data),...) ) which answers by the message "Fine, Jupiter!" (SEND(message , appl_ch ) ). These operations are specific to each instance.
Finally, the applications unregister themselves and free the allocated resources in the last part, which is common to both instances.
Related Topics
Instance declarations | RENDEZVOUS | MATCHED( ) | MATCHING( ) | NOTMATCHED( ) | NOTMATCHING( ) | WAITTIL