Re: [Valgrind-users] thread scheduling

[Tom H. <to...@co...>]

In message <453...@ai...>
        Pim Nijdam <pn...@ai...> wrote:

> I noticed that Valgrinds scheduler yields the processor to another 
> thread after excecuting N basic blocks. Does someone know why Valgrinds 
> scheduler uses slices instead of just relying on the scheduling of the 
> threads?

Because valgrind deliberately only allows one thread to run at a
time (because none of the translation machinery, or things like
memcheck, is threadsafe) so it has to switch threads manually.

All threads except the running one will be blocked waiting for
valgrinds master lock, which the set_sleeping call will release
allowing the kernel scheduler to give control to another thread.

> I try to run Valgrind 3.2.1 on an embedded system (ppc32) where the 
> application sets a fifo scheduling policy for the threads.
> Since I need to keep fifo scheduling I need to disable this slice 
> system. Is it save to comment out the following lines in the scheduler?
>
>   while(!VG_(is_exiting)(tid)) {
>        if (VG_(dispatch_ctr) == 1) {
> 	 VG_(set_sleeping)(tid, VgTs_Yielding); // <-- comment out
> 	 /* nothing */
> 	 VG_(set_running)(tid);                 // <-- comment out
> 	...
>
> This seemed to me the least aggresive change. Running this seems to be 
> fine, but I figured there would be a reason for this slice business and 
> maybe I screw it up.

With your change control will only ever move to a new thread when a
system call blocks, so a thread which makes no blocking system calls
will run forever.

Note that it is still the kernel scheduler which decide which thread
to run next when set_sleeping is called, so the thread should still
run in FIFO order if that is what you have told the kernel to do - all
we do is control when the switch occurs.

Tom

-- 
Tom Hughes (to...@co...)
http://www.compton.nu/