Julian Seward wrote: > On Wednesday 29 October 2008, Darryl Miles wrote: > [...] > > I see what you're saying. However ... > >> Then when VGs default scheduler selects the next thread to run there is >> also another event simply to notify the custom scheduler this is >> happening (for which the return value is ignored). > > you still seem to assume that Valgrind has some control over which > thread runs next. And it doesn't. A long time ago, in versions prior > to 2.2.0, V did do thread scheduling, by running all application threads > in one OS-level thread, but those days are long gone. Nowadays, if > an application creates N threads running natively, it will have N threads > when running on Valgrind too.
I had read somewhere that there wasn't concurrent execution of the target executable when run under valgrind but simulated concurrently (ala Uni processor system) I do not know how things are implemented. I also presume that at all times valgrind has control. For example of valgrind needed to execute a kernel call; there is nothing wrong with that even if it blocks. But valgrind must check for some intercept flag when the system call returns. This way conceptually the target executable doesn't see the return from system call just yet and valgrind can block/suspend it internally until that thread is allowed to run again. In relation to restricting CPUs Linux there is: sched_setaffinity(2) I practice I don't want the Linux kernel to run any thread of choice since I'm thinking valgrind would intercept thread creation and thread exit, all system calls, etc... so all these interception points have to do is check for an interrupt flag if its set then a slower path executes to work out who/why/what cause the flow of execution to be interrupted. But you are 100% correct I do not know how valgrind is really implemented in this regard but I agree with Tim it is possible. > Regarding Helgrind not finding threading bugs: we have now a pretty > good understanding of the various race detection algorithms that have > been implemented in the framework (helgrind-3.3, drd, helgrind-3.4, > HGDEV branch) and their strengths and weaknesses. If you have some > examples of cases where a race has not been detected, and you think > it should have been, and you can condense it down to a manageable > sized test program, I'd be interested to see it. Its machine code level threading issues I wish it to find via basic memory access checks. I'm sort of happy I am somewhat proficient with using posix threading primitives and designing modular sub-systems which interact with data in an organized way. So that level of threading problem while nice isn't exactly what I'm trying to use valgrinds view of whats going on to assist me with. The things I would like to use valgrind for is to verify correctness of say a threadpooler and other such specialized multi-threaded code, custom intra-thread interactions not necessarily using pure posix compliant API but sometimes direct assembler calls. I can setup testcases to present specific scenarios and extend the time spent locked. Im some situations it is okay for one thread to write and multiple threads to read the same location. In some situations I'd like VG to report the sequence of memory accesses made in the explicitly described group even if no access rules were no violated. This is so I can prove my test cases are thorough enough to create a specific access pattern that I expect to see. This is sort of like having not just ALLOW_READ, ALLOW_WRITE access mode bits but also REPORT_READ, REPORT_WRITE and TRIGGER_READ, TRIGGER_WRITE meaning that you want a report of the access pattern or not and in the case of trigger if access to these locations would trigger a report on all locations with report set. Maybe it sounds complex but it really isn't. What I can do is audit the memory access of the specific locations I am interested in. This is what valgrind is really good at. I just want to extend that with control of threads too. Darryl ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
