> 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
