<< Client/Server Testing - Using 4Test's parallel processing features | Client/Server Testing - The parallel statement >>
Client/Server Testing - Threads and concurrent programming
<< Client/Server Testing - Using 4Test's parallel processing features | Client/Server Testing - The parallel statement >>
concurrent
programming
execution of blocks of client code assigned to different Agents so that one
script can drive multiple client applications simultaneously. A thread is part
of the script that starts it; a thread is not a separate script. Each thread has its
own call stack and data stack. However, all the threads that a script spawns
share access to the same global variables, function arguments, and data types.
A file that one thread opens is accessible to any thread in that script.
operations to a client application, the normal reason for creating a
multithread script is so that each thread can drive test functions for one client,
which allows multiple client application operations to execute in parallel.
connected to the machine. Therefore you must direct the testing operations in
a thread to a particular Agent machine. The following sections, in particular
"Specifying the target" provide more details.
no single 4Test statement is atomic with respect to a statement in
another thread.
statements
statements parallel, spawn, rendezvous, and critical:
of statements in a new thread. Since the purpose of spawn is to initiate
concurrent test operations on multiple machines, the structure of a block
of spawned code is typically:
operations to the specified Agent.
threads that were spawned by the calling thread have completed. When
the last child thread exits, it unblocks the parent thread. The rendezvous
statement is unnecessary if it is the last statement at the end of the
testcase. If the calling thread has no child threads, rendezvous does
nothing.
blocks the calling thread until the threads it spawns have all completed. It
condenses the actions of spawn and rendezvous and can make code
more readable.