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 declarationsRENDEZVOUSMATCHED( )MATCHING( )NOTMATCHED( )NOTMATCHING( )WAITTIL