Re: [Valgrind-users] threads to queue

[Darryl M. <dar...@ne...>]

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