|
From: Konstantin S. <kon...@gm...> - 2010-06-01 08:44:05
|
[a bit of explanation why we need this] We are trying to implement an automated data race verifier, similar to http://code.google.com/p/data-race-test/wiki/RaceCheckerClass and the one mentioned in http://pages.cs.wisc.edu/~shanlu/paper/asplos184-zhang.pdf (search for ConMem-v). The idea is to put a short sleep around one racey access in thread T1 to give a chance to the second racey access to execute in thread T2 while T1 is sleeping. We already did it with PIN -- it was simple because PIN is multi-threaded and we just needed to call usleep(). See http://code.google.com/p/data-race-test/wiki/RaceVerifier With Valgrind it seems to be a bit trickier: if we call sleep() inside a helper function we will block the whole process because Valgrind is single-threaded. Question: how can I sleep in a helper function so that other threads get a chance to run? Thanks! --kcc On Fri, May 28, 2010 at 3:41 PM, Evgeniy Stepanov <eu...@go...>wrote: > Hi, > > what is the best way to add a delay to the instrumented code that will not > block other threads of a program? > > In more detail, I'm trying to slow down individual threads of a program in > specific places of code, and observe the behavior of other threads at that > time. > > AFAIK, multithreading is implemented in Valgrind in such a way that only > one thread is active at any moment of time, and threads are switched only > between IRSB's. Because of this, sleeping or busy looping in helper > functions does not work - it blocks the whole program. > > I've got some success with the following approach. I steal the address of > usleep() function from the program with a client request from vgpreload part > of the tool, and insert a call to that address during code instrumentation: > > // put sleep duration in %edi > PUT(56) = 0xF4241:I64 > // put return address on the stack > t15 = GET:I64(32) > t16 = Sub64(t15,0x8:I64) > PUT(32) = t16 > STle(t16) = 0x405F55:I64 > // call the stolen usleep() > if (1:I1) goto {Call} 0x40A012:I64 > > This code must be placed immediately before an IMark, whose address is the > return address of the call (0x405FF5 in this case). It also can not be > placed at the beginning of an IRSB, because valgrind complains about an > unknown PC. This approach is very arch-dependent and does not feel right. > > There is also an inconvenience that all instrumentation after this call is > lost after the callee returns, since the superblock is then split into two > that must be instrumented separately one more time. > > Is there a simpler way to do this? Is it possible to somehow tell the > valgrind scheduler to let the other threads run for a bit (some kind of > VG_(sched_yield) or VG_(sleep))? > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |