Russinovich, M. and B. Cogswell, Replay for concurrent non-deterministic shared-memory applications, in: PLDI, 1996.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the instruction and data references, where data references indicate which unique o#set is used. Work on Deterministic Replay. Most of the work in parallel program tracing is geared towards deterministic replay of executions (reconstructing and replaying an execution from recorded information) [10, 12, 19]. This is primarily useful for program debugging and comprehension; it does not require recording all shared memory accesses. However, our aim is not only to store enough information so that the current execution can be replayed . Indeed, one of the intended uses of our compact representation is ....

M. Russinovich and B. Cogswell. Replay for concurrent non-deterministic shared memory applications. In ACM International Conference on Programming Language Design and Implementation (PLDI), 1996.

....to some rules, reorder the sent messages with the intention to provoke a failure. Russinovich and Cogswell present a method that facilitates deterministic replay on nondeterministic shared memory uni processor systems in Replay for Concurrent Non Deterministic Shared Memory Applications (1996) [47]. The approach is called repeatable scheduling algorithm, and it ensures deterministic replay by forcing the system to make the same scheduling decisions during replay as during the reference execution. In order to do so, it requires the use of Software Instruction Counters. If the initial state ....

Mark Russinovich and Bryce Cogswell. Replay for Concurrent Non-Deterministic Shared-Memory Applications. In Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation, volume 31(5) of SIGPLAN Notices, pages 258 -- 266, May 1996.

....uniprocessor multi threaded environments in which the points of non determinism can be reduced to the thread switches. Therefore, they log the order of thread switches and ensure that thread switches occur in the same order during replay. Again, this approach has been used in concurrent debuggers [11, 13]. Given that the non determinism due to thread scheduling can be tracked and replayed, the general optimistic recovery approach described before can be used with a process as a recovery unit. The False Causality Problem An example of how the process centric approach operates is shown in Figure ....

M. Russinovich and B. Cogswell. Replay for Concurrent Non-deterministic Shared-memory Applications. Proc. ACM SIGPLAN Conf. on Programming Languages and Implementation (PLDI), 258-266, 1996.

....events messages and general input output operations. For example, repeated execution of a program is common while debugging a program, and non determinism may disallow a bug that appeared in one execution instance of the program from appearing in another execution instance of the same program [8, 13, 11, 10, 12, 5, 1, 2, 4]. A key missing element in current debuggers and monitoring tools for Java is the ability to provide a deterministic replay of a non deterministic execution instance. In this paper, we present a record replay tool for Java, called DejaVu, that enables deterministic replay of concurrent Java ....

....Finally, Section 7 concludes the paper. 2 Deterministic Replay Replaying a multithreaded program on a uniprocessor system can be achieved by first capturing the thread schedule information during one execution of the program, and then enforcing the exact same schedule when replaying the execution [12]. A thread schedule of a program is essentially a sequence of time intervals (time slices) Each interval in this sequence contains execution events of a single thread. Thus, interval boundaries correspond to thread switch points. Capturing the actual thread schedule information is not always ....

[Article contains additional citation context not shown here]

Mark Russinovich and Bryce Cogswell. Replay for concurrent non-deterministic shared-memory applications. Proceedings of ACM SIGPLAN Conference on Programming Languages and Implementation (PLDI), pages 258--266, May 1996.

....CREW (Concurrent Read Exclusive Write) and generates traces only for these coarse operations. Obviously, this approach will not work for applications that do not use the CREW discipline; but it also fails when critical events within CREW are non deterministic. Russinovich and Cogswell s approach [10] is similar to ours in that it captures thread switches (rather than all critical events) on a uniprocessor. They modified the Mach operating system so that it notifies the replay system of each thread switch. Since they do not replay the (operating system s) thread package itself, their replay ....

M. Russinovich and B. Cogswell. Replay for concurrent non-deterministic shared-memory applications. Proceedings of ACM SIGPLAN Conference on Programming Languages and Implementation (PLDI), pages 258--266, May 1996.

....CREW (Concurrent ReadExclusive Write) and generates traces only for these coarse operations. Obviously, this approach will not work for applications that do not use the CREW discipline, but it also fails when critical events within CREW are nondeterministic. Russinovich and Cogswell s approach [16] is similar to ours in that it captures thread switches (rather than all critical events) on a uniprocessor. They modified the Mach operating system so that it notifies the replay system on each thread switch. Since they do not replay the (operating system s) thread package itself, their replay ....

M. Russinovich and B. Cogswell. Replay for concurrent non-deterministic shared-memory applications. In Proceedings of ACM SIGPLAN Conference on Programming Languages and Implementation (PLDI), pages 258--266, May 1996.

....in another execution instance of the same program. Further, the performance can be different from one execution of a program to another execution of the same program. Providing deterministic replay of application execution is a key step towards programmer productivity and program understanding [5, 8, 4]. Towards this goal, we developed a replay framework based on logical thread schedules and logical intervals. An application of this framework was previously published in the context of a system called DejaVu that provides deterministic replay of multi threaded Java programs on a single Java ....

....and Section 8 concludes the paper. 2. Replay Framework Replaying a multithreaded program on a uniprocessor system can be achieved by first capturing the thread schedule information during one execution of the program, and then enforcing the exact same schedule when replaying the execution [8]. A thread schedule of a program is essentially a sequence of time intervals (time slices) Each interval in this sequence contains execution events of a single thread. Thus, interval boundaries correspond to thread switch points. 2.1. Logical Thread Schedule We refer to the thread schedule ....

[Article contains additional citation context not shown here]

M. Russinovich and B. Cogswell. Replay for concurrent non-deterministic shared-memory applications. Proceedings of ACM SIGPLAN Conference on Programming Languages and Implementation (PLDI), pages 258--266, May 1996.

....hardware [Baco91] software or hybrid probes. 5.2.1 Replaying on a monoprocessor Replay mechanisms based on the scheduling order of the different threads can be used for monoprocessor systems. Indeed, by imposing the same scheduling order during replay, an equivalent execution is constructed [Holl89, Russ96, Schu99]. This scheme can be extended to multiprocessor systems by also tracing the memory operations executed between two successive scheduling operations. In [Choi98] such an implementation for Java is described. Since a typical execution of a Java program has a small number of scheduler operations (no ....

M. Russinovich and B. Cogswell. Replay for concurrent nondeterministic shared-memory applications. In Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation, volume 31 of SIGPLAN Notices, 258--266, Philadelphia, Pennsylvania, 5 1996.

....the register might underflow. For example, a 32 bit register would underflow every 20 seconds of execution on a 200 MHz machine. Reinitializing the register at well defined points resolves this issue. The use of instruction counters has been suggested for debugging shared memory parallel programs [8, 25, 28]. Instruction counters may be available in hardware, as in the HP PA RISC architecture. They also can be emulated in software [25] The emulation uses the observation that a count of instructions is not strictly necessary for execution replay. Instead, a count of the branches taken by the program ....

M. Russinovich and B. Cogswell. Replay for concurrent non-deterministic shared memory applications. In Proceedings of the 1996 ACM SIGPLAN Conference on Programming Language Design an Implementation, pages 258--266, May 1996.

....hold. Execution proceeds until an event of interest occurs, at which time the content of the counter is sampled, and the number of instructions executed since the time the counter was set is computed. The use of instruction counters has been suggested for debugging shared memory parallel programs [36, 122, 148]. Instruction counters can be used in rollback recovery to track the number of instructions that occur between asynchronous interrupts. A replay system can use the instruction count to force the execution of the same number of instructions between asynchronous interrupts. An instruction counter ....

M. Russinovich, B. Cogswell, and Z. Segall. Replay for concurrent nondeterministic shared memory applications. To appear in Proc. SIGPLAN '96.

No context found.

Russinovich, M. and B. Cogswell, Replay for concurrent non-deterministic shared-memory applications, in: PLDI, 1996.

No context found.

M. Russinovich and B. Cogswell. Replay for concurrent nondeterministic shared-memory applications. In Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation, volume 31 of SIGPLAN Notices, pages 258--266, Philadelphia, Pennsylvania, 5 1996.

No context found.

M. Russinovich and B. Cogswell. Replay For Concurrent Non-Deterministic SharedMemory Applications. ACM Press, New York, Department of Computer Science, University of Oregon, Eugene OR 97403, 1996. Proceedings of the ACM SIGPLAN '96 conference on Programming language design and implementation http://doi.acm.org/10.1145/231379.231432 .

No context found.

M. Russinovich and B. Cogswell. Replay for concurrent nondeterministic shared-memory applications. In Proc. ACM SIGPLAN Conf. on Programming Languages and Implementation (PLDI), pages 258--266, 1996.

No context found.

M. Russinovich and B. Cogswell. Replay for concurrent nondeterministic shared-memory applications. In Proceedings of the ACM SIGPLAN 1996.

No context found.

Russinovich, M. and B. Cogswell, Replay for concurrent non-deterministic shared-memory applications, in: PLDI, 1996.

No context found.

Russinovich, M., and Cogswell, B. Replay for concurrent non-deterministic shared-memory applications. In Proceedings of the ACM SIGPLAN '95 Conference on Prog. Lang. Design and Implementation (PLDI), June, 1995.

No context found.

M. Russinovich and B. Cogswell. "Replay for concurrent non-deterministic shared memory applications." In Proceedings of the 1996 ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 258---266, May 1996.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC