object references/memory access

[John Nagle]

Karthik Gurusamy wrote:
> On Jul 2, 10:57 pm, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> 
>>>>>I have found the stop-and-go between two processes on the same machine
>>>>>leads to very poor throughput. By stop-and-go, I mean the producer and
>>>>>consumer are constantly getting on and off of the CPU since the pipe
>>>>>gets full (or empty for consumer). Note that a producer can't run at
>>>>>its top speed as the scheduler will pull it out since it's output pipe
>>>>>got filled up.
>>...
> If the problem does not require two way communication, which is
> typical of a producer-consumer, it is a lot faster to allow P to fully
> run before C is started.
> 
> If P and C are tied using a pipe, in most linux like OS (QNX may be
> doing something really smart as noted by John Nagle), there is a big
> cost of scheduler swapping P and C constantly to use the CPU. You may
> ask why? because the data flowing between P and C, has a small finite
> space (the buffer). Once P fills it; it will block -- the scheduler
> sees C is runnable and puts C on the CPU.

    The killer case is where there's another thread or process other than C
already ready to run when P blocks.  The other thread, not C, usually
gets control, because it was ready to run first, and not until the other
thread runs out its time quantum does C get a turn.  Then C gets to
run briefly, drains out the pipe, and blocks.  P gets to run,
fills the pipe, and blocks.  The compute-bound thread gets to run,
runs for a full time quantum, and loses the CPU to C.  Wash,
rinse, repeat.

    The effect is that pipe-like producer-consumer systems may get only a small
fraction of the available CPU time on a busy system.

    When testing a producer-consumer system, put a busy loop in the
background and see if performance becomes terrible.  It ought to
drop by 50% against an equal-priority compute bound process; if
it drops by far more than that, you have the problem described here.

    This problem is sometimes called "What you want is a subroutine call;
what the OS gives you is an I/O operation."  When you make a subroutine
call on top of an I/O operation, you get these scheduling problems.

					John Nagle