mattjones@cix.co.uk (Matthew Jones) wrote:

> My take on this, FWIW, is that disk access is involved. What happens is
> that DBISAM will make an OS call, and try to read from disk. That causes a
> small pause to the thread since the data has to be read, and another
> thread will take over the processor. When that thread finishes, the
> scheduler will awaken the DBISAM thread again, and give it to the next
> free processor. The disk thread may still be running, so it switches
> context to the other processor. Hence it flips across the processor each
> time.
>
> /Matthew Jones/

Matthew,
      It looks like you're right. If I assign my app to use only one
processor, the processor is pegged at 100% and the other processor drops
to near 0. If I switch it back to using 2 processors, both processors
are around 50%, so it looks like it is just trading work (my app)
between processors so one processor is never overtaxed. Neat.

Dave