Darryl Miles <[EMAIL PROTECTED]> writes:
> Julian Seward wrote:
> > I can't claim to really understand this, but I do have a couple of
> > questions:
> >
> > * "it knows that T2 is blocked in the kernel"
> > how does V know that a syscall it is about do perform (on behalf
> > of the client application) will or will not block?
> > AFAICT that is unknowable from user space. And how would it
> > distinguish a block from merely a long wait?
>
> It would work on the basis that Valgrind knows a syscall is being
> performed, its running the application/client under emulation and it has
> already intercepted the entrypoints to all syscalls.
>
> Valgrind already does a similar thing (but at a higher level up) for
> malloc/free/realloc etc.
You missed his question -- valgrind sees (essentially):
read(42, &mybuf, 1024);
Is this system call going to block? Or are we going to return to user
code without any context switches? It is impossible to know a priori,
unless we can peek into the kernel.
Anyway I don't think this question is relevant anymore -- with the
lock approach, yuo don't care whether things block.
> > Do you have any concise fragments of code illustrating what problem
> > it is you are really trying to solve?
>
> "Concise" might seem a little subjective.
Look at it from a developer point of view. Think of a stupid, 10 line
program that you don't actually want to debug because it's easy, and
show the output you'd want to get from valgrind on that program.
I'll make up an example:
T1 T2 T3 T4
acquire(&x) acquire(&x) read(abc) write(abc)
write(abc) read(abc) y = abc*18 z =42/abc
release(&x) release(&x) ... whatever ..
Darryl (I think) wants to see is something like:
while in T1's C.S. `x', the variable `abc':
saw a write from T1 of size whatever
saw a write from T4 of size whatever
saw a read from T3 of size whatever
saw a read from T4 of size whatever
(of course, that's just one possible ordering that I'm making up)
Where those `saw a' lines define a total ordering of the memory access
to `abc'.
Having this sort of audit is useful for deriving/proving ideas such
as, `if I can guarantee that T1 always writes before T* reads, then my
system will always have the correct result'. This is a bit
lower-level than a simple race detection algorithm, which takes these
kinds of accesses and has built-in logic to decide whether or not they
are acceptable. Furthermore, as I understand `Eraser' at least [1],
there is no notion of `history' -- variables have a state, and there
is a state transition graph which changes based on which locks are
held as data are accessed, but there is nothing which keeps track of
the path travelled through that state transition graph.
[snip]
I don't think the rest is relevant until we see a first stab at an
implementation.
-tom
[1] I have a vague recollection that Helgrind was based on that
algorithm, back in the day..
-------------------------------------------------------------------------
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
