This section describes the scheme of debugger compatibility for debugging multithread programs.
When multiple threads are running in a process of a debugged program, debugging can be essentially performed on only one thread at a time. The thread on which debugging can be performed is called the implicit thread. Any thread can be debugged by switching the implicit thread to it. The implicit thread can be switched from the Thread List window.
Because the debugger window or dialog box displays information on the implicit thread, multithread programs can be debugged in the same manner as single-thread programs.
System and server applications may have some threads other than COBOL applications threads. It is necessary to use the same actions as with multithread applications when these applications are debugged.
While the debugging function basically works on the implicit thread as if it were a single thread, the following operations are specific only to multithreads:
Breakpoints
Passage count points
Execution
Watch data/Watch conditional expression
Backward trace
Because a breakpoint is effective for all threads, all threads stop at the specified breakpoint. Moreover, the passage count of each thread is counted. The passage count is initialized to zero by subsequent execution of any procedure after a thread ends, though the passage count is maintained until the time the thread ended.
Because a passage count is effective for all threads, the number of times a thread passes the passage count point is counted. The passage count is initialized to zero by subsequent execution of any procedures after a thread ends, though the passage count is maintained until the time the thread ended.
To check the passage count when threads other than the implicit thread end, therefore, specify on the [Operation] page in the [Environment] dialog box, a program execution break at thread end.
When a program is executed unconditionally, all threads are run simultaneously.
If a program is executed to a target position, the implicit thread is run under specified conditions. All threads other than the implicit thread are run unconditionally at this time.
While watching data shared by threads, the watch data or watch conditional expression function detects successful monitoring when a thread changes the data being monitored.
While watching data not shared by threads, the function also detects successful monitoring, even when the data is changed by another thread.
The backward trace function can be executed in one of two modes: in one mode the function traces back only the implicit thread, and in another mode the function traces back all threads.
In multithread trace mode, the backward trace function traces threads in order of execution. The thread currently traced is automatically displayed in the Source File window.
You can visually review the flow of control among the threads.
The following debug functions help to debug multithread programs efficiently:
Enable/disable debugging event notifying
Suspend/resume
Notification of debugging events, such as monitoring and breakpoint halts, can be enabled or disabled for each individual thread.
When debug event notification is disabled for a thread, the thread is run, but interruption events for debugging, such as monitoring and arrival at a breakpoint, will not be notified.
This function can be specified from the Thread List window.
The suspend/resume function limits the action of threads during program execution.
If a thread is suspended, it remains at the current position when the program is run. If a suspended thread is resumed, it comes into operation the next time a program is run.
This function can be specified from the Thread List window.
With batch debugging and automatic debugging functions, the debugger can reproduce debugging procedures.
Though these functions can also be used for debugging multithread programs, certain points deserve special notice in reproducing debugging procedures for multithread programs:
Generate threads in the same order as that in which debugging procedures are recorded.
The debugger identifies each individual thread on the basis of the order in which it is generated in the process. This order is known as a thread ID. Debugging procedures are performed on threads that are identified by their thread IDs. To reproduce a debugging procedure performed on a given thread, the order in which the thread is generated must be set to equal the order in which the debugging procedure is recorded. Threads might not be generated in order, according to the system and the server application. In that case, it is not possible to automate debugging.
Notify debugging events to only one thread during program execution.
When multiple threads are run concurrently, debugging events may be notified to different threads between the two instances of recording and reproduction, depending on how the OS allocates CPU time to the individual threads. Where a program is run with unconditional execution or breakpoint execution specified, having non-implicit threads to which debugging events may be notified or suspended can avert this problem.
