On Feb 16, 2008 1:40 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > I think those don't serve my needs. First of all, I'm fiddling with > multiple processes, not multiple threads. Second, I'm not after race > conditions on shared memory access, which can be detected automatically. > But I want to check the outcome of a parallel program against an > expected result. That may depend on the scheduling (but should not) as > well as on other events. As bugs triggered by rare scheduling decisions > are very hard to reproduce, I'm looking for something to force uncommon > scheduling.
If you want to record and replay the order of events in multiple cooperating processes, you will have to do the following: - Find out which information is exchanged between the threads of a single process and that affects the behavior of a that process, just like exp-drd does. - Find out which information is exchanged between processes that affects the behavior of the group of processes. This can include socket communication, POSIX signals, data read from or written to files, file locking, ... Maybe it's a better idea to implement a daemon process that collects and replays this kind of information at the level of the Valgrind tool than to let the client processes collect and replay this information. As far as I now a record/replay mechanism for groups of processes has not yet been implemented. This looks like an interesting research topic. Bart Van Assche. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
