Re: [Valgrind-users] Question about Valgrind

[Siddharth N. <si...@gm...>]

Hi All,

Is there are theoretical situation where a single thread could
repeatedly be trying to acquire a lock (as dictated by the user
program) or will Valgrind switch this thread out or will the Linux
system detect this and intervene successfully?
Futexes don't do system calls until there is sufficient contention.
There will not be sufficient contention when threads are serialized
correct? So with no system calls, Valgrind will not really have a
reason to switch a thread out even when it is not really doing much
other than waiting on a lock. Is this correct?

Sid

On 23 March 2012 13:45, Julian Seward <js...@ac...> wrote:
>
>> In sum, you should get one *possible* execution, but it won't necessarily
>> be one typical of truly concurrent execution.  (Just because you have
>> threads that are *runnable* at the same time does not mean that they
>> actually run *concurrently* in a real system, unless you guarantee
>> multuple cpus are available. You can think of valgrind as providing a
>> universe where only one cpu is *ever* available.)
>
> You can get round robin scheduling of runnable threads using
> --fair-sched=yes.  And you can change the quantum to something a lot
> lower by changing this value
>
> ./coregrind/m_scheduler/scheduler.c:#define SCHEDULING_QUANTUM   100000
>
> to (eg) 1000.  Performance will be a lot worse, but you'll get much
> finer grained interleaving.
>
> Note that when https://bugs.kde.org/show_bug.cgi?id=296422 lands
> it will somewhat reduce this effect, since one minor effect of it is
> to reduce the number of event (timeslice-out) checks by about a factor of 3.
>
> J
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users