Re: [Valgrind-developers] processes and threads

[Markus S. <ma...@bl...>]

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" doesn't do the deciding, but 
just blocks threads appropriately, right? However, properly blocking, 
you could override the kernel's decisions, in a way.

But after a fork, do the two processes still serialize their execution 
slots? Or do they run independently?

> You'd be better off trying out one of the threading tools in 3.3.0
> (Helgrind or Exp-drd).

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 want to check the outcome of a parallel program against an 
expected result. That may depend on the scheduling (but should not) as 
well as on other events. As bugs triggered by rare scheduling decisions 
are very hard to reproduce, I'm looking for something to force uncommon 
scheduling.

Favorably even in conjunction with being able to control outside events. 
So that I could write expected execution plans, somewhat like:

  - after starting, I'm expecting a fork()
  - let the parent receive data on a socket
  - expect the child to get a signal SIGUSR2
  - interrupt the parent
  - expect the parent to get back a signal SIGUSR2
  - let the parent continue
  - expect data packet X from parent via socket

In the scenario above, I let the child do the processing, first, and 
only allow the parent to do it's processing after the child finished 
(which it signals to the parent). The other extreme variant would be:

  - after starting, I'm expecting a fork()
  - let the parent receive data on a socket
  - expect the child to get a signal SIGUSR2
  - interrupt the child
  - let the parent process until it waits for the
    SIGUSR2 from the child.
  - let the child continue
  - expect the parent to get back a signal SIGUSR2
  - let the parent continue as well
  - expect data packet X from parent via socket

Now, this is largely simplified, as it involves only two signals, which 
the child and parent use to synchronize. However, in practice, I'm 
facing more processes as well as multiple states. I'd like to test every 
possible combination thereof.

If you know of a better way to do that, I'd be curious to know, too. But 
so far, even when looking for "automated debugging" and things like 
that, I didn't find anything close to what I'm looking for.

Regards

Markus