Fig 4 - uploaded by Akinori Yonezawa
Content may be subject to copyright.
Node Local Scheduling 

Node Local Scheduling 

Source publication
Article
Full-text available
Concurrent programs often exhibit nondeterministic behavior because execution order of concurrent events may involve some arbitrariness. Such indeterminacy makes it difficult to find the sources of program errors. We propose a debugging scheme for fine-grain parallel programs on massively parallel processors. It facilitates (1) replay of a specific...

Contexts in source publication

Context 1
... our debugging system can not physically execute events in the order that the user wants to execute. For ex- ample, node local scheduling is shown in Fig.4. The thick arrows in gure (b) indicate the actual physical execution of events in a node. ...
Context 2
... time the user wants to trace an execution path, our debugging sys- tem executes all the events in the same order as they were scheduled in the monitoring phase, but displays only the events on the execution path that the user wishes to trace. In the example of Fig.4, when the user wishes to trace path1:a0!a1!a2, the debugging system must execute all the events a0, b1, b2, c0, b3, c1, a1, and a2 \internally", following the original scheduling or- der. ...
Context 3
... the user switches to another execution path to trace it, our debugging system have to rewind to the time when the scheduler initiates the rst event to be traced on the execution path. In the example of Fig.4, suppose the user is trac- ing two execution paths, path1:a0!a1!a2 and path2:a0!b1!b2!b3!c1!c2, and has already traced path1 up to a2. ...
Context 4
... a mechanism to distinguish the events not executable in the user's views from those executable, our replay system would accept the user's request to execute events that are not executable. In the example of Fig.4, suppose that the user is tracing path2, and tries to execute c2 without executing a2 on path1. ...

Similar publications

Article
Full-text available
Detecting data races in multi-threaded programs is a challenging problem in debugging, because the races could reveal nondeterministic program behavior in execution of such pro- grams. Nondeterministic runtime effects of a race are hard to identify and it is difficult to decide whether the reported data races can appear or not in the actual program...
Article
Full-text available
Ensuring the reliability of structured fork-join parallel programs is difficult because the potential for subtle interactions between concurrent threads can cause concurrency bugs, such as data races, which are hard to detect, reproduce, and eliminate. The visualization for the executions of the programs may offer effective debugging environments w...