Re: [Valgrind-users] thread scheduling

[Pim N. <pn...@ai...>]

Thanks for your reply.

Tom Hughes wrote:
> 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.
Ah, that's the thing I forgot: all other threads are blocked and won't 
be scheduled by the kernel.

> 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.
That's the point. When a thread is 'sleeping' (blocked for valgrind's 
run semafor) another thread will be scheduled. But maybe there was no 
reason (higher priority thread) to switch to another thead. I'm 
concerned that instead of running one thread untill say a higher 
priority thread is scheduled. Two threads will run interleaved (one with 
possibly a lower priority). Is my concern grounded?

Pim Nijdam

-- 
This message has been scanned for viruses and is believed to be clean