> Remember my rule: All threads in a kernel system call are running (and
> maybe put to asleep inside the kernel if it so wishes). As soon as the
> kernel passing back control via system call return you always intercept
> with valgrind doing a "Can I still run check? Yes=carry on, No=go to
> sleep under valgrind's control".
>
> Why would valgrind keep waking up the wrong thread, it wont do that with
> round-robin since it knows that T2 is blocked in the kernel (waiting for
> the lock).
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?
* "No=go to sleep under valgrind's control"
how?
-------
Overall I have to say my feeling is that messing with the kernel's
scheduling is a losing proposition. We went to those kinds of places
in earlier years of the project, and it was always a massive PITA
and source of fragility.
It also seems to me that both you and Felix want to control the
scheduling as a way of shaking out threading-related bugs in applications
(but correct me if I'm wrong). FWIW, if that is indeed the case,
I would suggest that you'd be better off looking into race detection
algorithms which are more scheduling-independent and/or can understand
atomic instructions better (I think you mentioned something about them
earlier in the thread).
Do you have any concise fragments of code illustrating what problem
it is you are really trying to solve?
J
-------------------------------------------------------------------------
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
