On Feb 17, 2008 11:35 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> Hm.. that's a point. But using mainly shared memory for inter process
> communication, this won't help, because there's no (or only few) system
> calling involved. So the scheduling might very well differ.
Regarding sharing
Hi,
Bart Van Assche wrote:
> I think that it is possible to implement a record/replay tool for
> multiple processes without modifying the Valgrind scheduler. During
> the recording phase you can gather information about any event that
> influences interprocess ordering by intercepting system calls
On Feb 17, 2008 11:05 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> However, what bugs me more is, that there would need to be an interface
> to valgrind, to control the internal scheduler (to be able to start and
> stop threads or processes based on some external events).
I think that it i
Hi,
Nicholas Nethercote wrote:
> Valgrind really only does intra-process simulation/emulation. It seems
> to me you'd need something that simulates/emulates multiple processes.
> Maybe a whole system simulator of some kind -- Bochs or SimICS?
Yes, I'm partly working with system virtualization
On Sat, 16 Feb 2008, Markus Schiltknecht wrote:
> Aha, so the valgrind's internal "scheduler" doesn't do the deciding, but
> just blocks threads appropriately, right? However, properly blocking,
> you could override the kernel's decisions, in a way.
I guess so.
> But after a fork, do the two pro
On Feb 16, 2008 1:40 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> I think those don't serve my needs. First of all, I'm fiddling with
> multiple processes, not multiple threads. Second, I'm not after race
> conditions on shared memory access, which can be detected automatically.
> But I wan
Hello Julian,
Julian Seward wrote:
> Indeed; it seems a bit pointless to mess with the scheduler. In
> any case it does not control the order in which threads run --
> the kernel does that. It only really ensures that one thread
> runs at any one time.
Aha, so the valgrind's internal "scheduler
On Saturday 16 February 2008 11:43, Bart Van Assche wrote:
> On Feb 16, 2008 10:35 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> > I would like to simulate the scheduler, or even influence it, to be able
> > to reproducibly test execution of concurrent code. Because as commodity
> > hardware
Hello Bart,
Bart Van Assche wrote:
> This makes me wonder why you would like to do this ? Is it because you
> want to be able to debug race conditions in concurrent code ? In that
> case, please have a look at the exp-drd project -- this might be what
> you are looking for.
Thanks, I've taken a l
On Feb 16, 2008 10:35 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> I would like to simulate the scheduler, or even influence it, to be able
> to reproducibly test execution of concurrent code. Because as commodity
> hardware gets more and more CPU cores, multi-threaded code will get more
>
Hello valgrind developers,
I've been studying the source code of valgrind to figure out how it
deals with processes and threads. And I'd like to make sure my
understanding is correct.
From the system call wrappers, I conclude that a fork() (or rather
clone) is passed down to the kernel, so th
11 matches
Mail list logo
