Darryl Miles <[EMAIL PROTECTED]> writes:
> Julian Seward wrote:
> > Yes, I guess so. Although I'm not sure how this could be implemented.
> > The trick with the pipe in sema.c implements a lock well enough, but how
> > does one implement a lock in which (1) the unlocker can control which
> > thread gets the lock next, and (2) that signalling is somehow implied to
> > the kernel, so as to force it to "decide" on our behalf? I'm not sure.
> >
> > Also, deciding ourselves which thread is next to run is dangerous.
> > If we decide to run thread X (and cause all the rest to be blocked), but
> > for some reason that we don't anticipate, the kernel believes X to be
> > blocked, then the system will deadlock.
>
> Are you in "user code" or in "kernel code" ? The point I am making is
> that all system calls must be allowed to run immediately and allowed to
> block inside the kernel; this means the act of invoking a kernel call
> must always release/ensure at least one other thread that should be
> running in "user code" is unblocked to run (just in case this thread
> blocks inside the kernel).
>
> Then on the return from the system call the current thread checks to see
> if it is still allowed to run, if it is not allowed to run it suspends
> itself.
You miss his point. Say we have two threads:
T1 T2
pthread_mutex_lock(&m); pthread_mutex_lock(&m);
ht->add(key, value); ht->remove(key);
pthread_mutex_unlock(&m); pthread_mutex_unlock(&m);
Now say thread 1 acquires the lock. Finally, this logic of valgrind
deciding which thread to run decides (through bug or otherwise) that
thread 2 should run. Both threads are currently paused. Then:
The kernel decides to wake thread 1. Valgrind sees `runnable thread'
!= `current thread', and does a sched_yield(). The kernel decides to
wake thread 1. Valgrind sees `runnable thread' != `current thread',
and does a sched_yield(). The kernel decides to wake thread 1 ...
That was two threads, with one lock. Think of how difficult getting
this right would be for 10 threads and 10 locks -- and that's still a
small program!
The only way I can see to fix this is to have some sort of scheduling
logic inside valgrind itself, which takes into account which threads
hold which locks (or shmem semaphores, or anything else that might
block the app). Julian's argument (correct me if I'm wrong) was that
creating such a scheduling algorithm is going to be extremely
difficult.
[snip -- lots of stuff I'm clueless about]
> That is the ability to control/suspend thread execution/scheduling
> within a process (possibly itself, possibly another process) but doing
> so in a way that is not observable to the application. This might have
> other uses outside debugging but mainly targeted at debugging.
Could you write a wrapper application which fork/execs your chosen
application? This wrapper could use ptrace to start/pause the
application, and you could communicate with it however you choose, or
even just programmatically specify what you'd like.
.. actually, that sounds a lot like gdb, to be honest. Maybe I'm
missing something.
-tom
-------------------------------------------------------------------------
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
