Question & Answer
Question
What multi-threaded option settings do you need to use for Runtime Analysis and Component Testing of the IBM® Rational® Test RealTime®?
Cause
Multi-threaded applications can be pre-emptive or non-pre-emptive.
Answer
When instrumenting multi-threaded applications, you need to set multi-threaded options in Test RealTime (TestRT) in the following cases.
- You need to use the --atl_multi_threads=1 option when the application under test use pre-emptive multi-threading.
The reason for this is that the option --atl_multi_threads=1 causes the runtime library to protect data structures from parallel updates.
For code coverage the data structure is a linked list of the files under test, a simultaneous update of this list may cause files to drop out of the list.
The overhead of this option is that nearly all calls to the TestRT runtime library result in a mutex. This mutex is taken at the beginning of the call and releasing of the mutex at the call. If you are only using code coverage (and not with -count), there is one call to the runtime at the beginning of each function.
How much this impacts the application under test depends upon the application and how quickly the underlying operating system can take and release mutexes. If you have a clock available, you can use TestRT to measure it by writing two functions. One that takes and releases a mutex and that does nothing. Then calling each function 1000 times (or whatever it takes to get a reasonable measure and using Performance Profiling to measure the time spent in each function.
- With non-pre-emptive multi-tasking then question you must verify the following things.
- Can you guarantee that the TestRT runtime library will not be interrupted?
There will be not posisble to have 2 threads will execute code in the TestRT runtime library simultaneously?
- If that is true then you do not need to use the --atl_multi_threads=1 option.
Note:
Non-pre-emptive multi-tasking usually implies that each thread relinquished control to another thread by calling a system function. This system call is not in the TestRT runtime library but in the application code. As a consequence, you can remove the --atl_multi_threads=1 option and still get correct results.
Using Test RealTime GUI with a project
Using command line with attolcc
Using command line with the instrumentor directly(attolcc1,attolccp)
Using Component Testing for C++
Using Component Testing for Java
Using the instrumentor with Rose® RealTime integration
Using the instrumentor with MS Visual Studio integration
Using Test RealTime GUI with a project
- Open the Project Settings dialog, Project > Settings..., and choose as follows.
- Set 'Yes' in Build > Target Deployment Port > Multi-threaded application .
- Set the correct maximum number of threads in Build > Target Deployment Port > Maximum number of threads (the default is 64).
- Set to 'Yes' in Runtime analysis > Runtime tracing > Runtime options > Record and display thread info.
- Rebuild your application completely.
Using command line with attolcc
- Add the option, --atl_multi_threads=1 --no_sys_include, to the attolcc command:
% attolcc --atl_multi_threads=1 --no_sys_include ...
- Add the option, --atl_threads_max=<number>, to reset the default (64) maximum number of threads. Should be use when the threads number is expected to be larger than 64.
Notes:
- For priors version at Test RealTime 7.x you must use the following options
.--atl_multi_threads=1 --no_sys_include -SET=MULTITHREAD,NO_SYS_INCLUDE,
as follows:
% attolcc --atl_multi_threads=1 --no_sys_include -SET=MULTITHREAD,NO_SYS_INCLUDE ...
- Use the option, --no_sys_include, if the application includes system files, such as windows.h or pthread.h.
Using command line with the instrumentor directly (attolcc1, attolccp)
- Add the -MTSUPPORT option to the instrumentor as in the following example.
% attolcc1 <source> <output> <definitions> <options> -MTSUPPORT
- Compile the TDP (TP.o) with multi-threaded option (like -pthread). In many compilers that option is set by default.
Using "Component Testing for C++"
- Select Yes for Reentrant objects in Project > Settings > Component testing for C++ > Contract check options .
This ensures granularity for state evaluation. This option has no effect if multi-thread support is not activated in the Target Deployment Compilation Settings.
Using "Component Testing for Java"
Component Testing for Java cannot be applied to multi-threaded Java components.
Using a customized TDP
- Check your TDP > Library Settings > Thread Interface to make sure RTRT_THREADS contains the correct values.
- Use the TDP Manual for additional information.
Using the instrumentor with Rose® RealTime integration
- Right-click the model, select Component Specification,
- Add the option "--no_sys_include" in the field Additional Options on the tab for Test RealTime
Using the instrumentor with MS Visual Studio integration
- Go to the menu, Tools > Rational Test RealTime option.
- Add the appropriate options in Others in the TestRT setup window.
Note: The multi-threaded mode in Test RealTime protects Target Deployment Port global variables against concurrent access. The multi-threaded option causes a significant increase in Target Deployment Port size as well as negatively impact performance. Therefore, select this option only when necessary.
For more information, consult the Test RealTime on-line documentation .
[{"Product":{"code":"SSSHUF","label":"Rational Test RealTime"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Documentation","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.5;7.5.0.4;7.5.0.5;7.5.0.6;8.0;8.0.0.1;8.0.0.2;8.0.0.3;8.0.0.4","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21264288