Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/DD/MultiContext"
m |
m |
||
Line 8: | Line 8: | ||
*:; ''Scenario'': | *:; ''Scenario'': | ||
*:;:* ''Step'' | *:;:* ''Step'' | ||
+ | |||
* I. Programs with multiple threads | * I. Programs with multiple threads | ||
+ | |||
*;1 Two or more threads interacting : User is debugging a program with multiple threads which are interacting with each other. | *;1 Two or more threads interacting : User is debugging a program with multiple threads which are interacting with each other. | ||
*:; a) Debugging threads which contend for the same lock. : | *:; a) Debugging threads which contend for the same lock. : | ||
Line 24: | Line 26: | ||
*:;:# User sets another breakpoint further down in routines that access the shared data. | *:;:# User sets another breakpoint further down in routines that access the shared data. | ||
*:;:# User continues some or all of the threads which stopped at the first breakpoint so that they may reach the second breakpoint. | *:;:# User continues some or all of the threads which stopped at the first breakpoint so that they may reach the second breakpoint. | ||
− | * | + | |
− | *:; a) User debugs | + | *;2 Debugging a subset of threads : User is debugging a program with multiple threads, but he is interested only in interacting with some of the threads. |
+ | *:; a) User debugs with breakpoints restricted to a sub-set of threads. | ||
*:;:# User creates a breakpoint on the routine to be debugged. | *:;:# User creates a breakpoint on the routine to be debugged. | ||
*:;:# User defines which threads should be allowed to hit the breakpoint. | *:;:# User defines which threads should be allowed to hit the breakpoint. | ||
*:;:# The threads hit the breakpoint and user steps through them. | *:;:# The threads hit the breakpoint and user steps through them. | ||
− | *:;: | + | *:; b) Run control for a subset of threads : User repeatedly suspends and resumes a subset of threads. |
− | *:;:# User continues debugging the | + | *:; c) Terminating/re-launching : |
+ | *:;:# User debugs a subset of threads (using filtered breakpoints, etc.). | ||
+ | *:;:# User terminates and relaunches a process, and continues to debug the same set of threads. | ||
+ | |||
+ | *;3 Program with large number (100+) of threads : User is debugging programs with large numbers of threads and he needs to manage those threads effectively. | ||
+ | *:; a) User needs to switch between suspended threads | ||
+ | *:;:# User sets a breakpoint that some threads may hit. | ||
+ | *:;:# Some threads hit the breakpoint. | ||
+ | *:;:# User switches focus between suspended threads to control them and examine their data. | ||
+ | *:; b) Threads created/destroyed rapidly: User is debugging a process with threads being created and destroyed at a rapid rate (more than 1 thread/sec.) | ||
+ | |||
− | * | + | * II. Multiple processes that interact with each other |
− | * | + | * III. Systems with multiple cores |
Revision as of 00:37, 3 April 2008
This sub-group is focused on improving the workflow of multi-context debugging. Multi-context refers to simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views.
Use Cases
Format:
- Family of use cases
- Use case
- Description of the use case
- Scenario
- Step
- I. Programs with multiple threads
- 1 Two or more threads interacting
- User is debugging a program with multiple threads which are interacting with each other.
- a) Debugging threads which contend for the same lock.
- When a thread blocks while stepping,
- User switches focus to another thread and steps until the lock is released,
- User switches focus back to the first thread and continues debugging.
- b) Debugging race conditions where multiple threads are reading and writing some shared data
- User sets a breakpoint at a location where a shared variable is written.
- Multiple threads hit the breakpoint
- User looks at each threads to see the thread-private data in each thread.
- User steps the threads individually to watch what happens to the shared data.
- Alternatively, user steps all threads.
- Multiple threads may hit the breakpoint at the same time.
- User sets another breakpoint further down in routines that access the shared data.
- User continues some or all of the threads which stopped at the first breakpoint so that they may reach the second breakpoint.
- 2 Debugging a subset of threads
- User is debugging a program with multiple threads, but he is interested only in interacting with some of the threads.
- a) User debugs with breakpoints restricted to a sub-set of threads.
- User creates a breakpoint on the routine to be debugged.
- User defines which threads should be allowed to hit the breakpoint.
- The threads hit the breakpoint and user steps through them.
- b) Run control for a subset of threads
- User repeatedly suspends and resumes a subset of threads.
- c) Terminating/re-launching
- User debugs a subset of threads (using filtered breakpoints, etc.).
- User terminates and relaunches a process, and continues to debug the same set of threads.
- 3 Program with large number (100+) of threads
- User is debugging programs with large numbers of threads and he needs to manage those threads effectively.
- a) User needs to switch between suspended threads
- User sets a breakpoint that some threads may hit.
- Some threads hit the breakpoint.
- User switches focus between suspended threads to control them and examine their data.
- b) Threads created/destroyed rapidly
- User is debugging a process with threads being created and destroyed at a rapid rate (more than 1 thread/sec.)
- II. Multiple processes that interact with each other
- III. Systems with multiple cores
Problems with Current Workflow
Proposed Changes
Old Documents
This sub-group was created following a discussion about platform debug dev: "ideas for improving multi-context debugging".