TotalView has two types of groups: process groups and thread groups. Process groups only contain processes, and thread groups only contain threads. The threads in a thread group can be drawn from more than one process.
TotalView has four predefined groups. Two of these only contain processes, while the other two only contain threads. TotalView also lets you create your own groups, and these groups can have elements that are processes and threads. The following are the predefined process groups:
• Control Group
Contains the parent process and all related processes. A control group includes children that were forked (processes that share the same source code as the parent) and children that were forkedbut subsequently called the execve() function.
Assigning a new value to the CGROUP(dpid) variable for a process changes that process’s control group. In addition, the dgroups -add command lets you add members to a group in the CLI. In the GUI, you use the Group > Custom Groups command.
• Share Group
Contains all members of a control group that share the same executable. TotalView automatically places processes in share groups based on their control group and their executable.
NOTE >> You can’t change a share group’s members. However, the dynamically loaded libraries used by group members can be different.
In general, if you’re debugging a multi-process program, the control group and share group differ only when the program has children that it forked by calling the execve() function.
The following are the predefined thread groups:
• Workers Group
Contains all worker threads from all processes in the control group. The only threads not contained in a workers group are your operating system’s manager threads.
• Lockstep Group
Contains every stopped thread in a share group that has the same PC. TotalView creates one lockstep group for every thread. For example, suppose two threads are stopped at the same PC. TotalView creates two lockstep groups. While each lockstep group has the same two members, they differ in that each has a different TOI. While there are some circumstances where this is important, you can usually ignore this distinction. That is, while two lockstep groups exist if two threads are stopped at the same PC, ignoring the second lockstep group is almost never harmful.
The group ID value for a lockstep group differs from the ID of other groups. Instead of having an automatic and transient integer ID, the lockstep group ID is pid.tid, where pid.tid identifies the thread with which it is associated. For example, the lockstep group for thread 2 in process 1 is 1.2.