I noticed that when I run my embedded DbIsam 2.46 app, both cpu's run up
to 50% or slightly more. (Using AMD 4400 dual-core) If I stop the
application then both CPU's drop down to zero. How is it possible for an
embedded application (non-multi threaded) to use more than 1 cpu?

TIA
Dave

"Dave Harrison" <daveh_18824@spammore.com> wrote in message
news:B837AC10-D58B-4359-9515-3041EE0051E7@news.elevatesoft.com...
>I noticed that when I run my embedded DbIsam 2.46 app, both cpu's run up to
>50% or slightly more. (Using AMD 4400 dual-core) If I stop the application
>then both CPU's drop down to zero. How is it possible for an embedded
>application (non-multi threaded) to use more than 1 cpu?

This is something windows does with most applications. Don't worry.

Uffe Kousgaard wrote:
> "Dave Harrison" <daveh_18824@spammore.com> wrote in message
> news:B837AC10-D58B-4359-9515-3041EE0051E7@news.elevatesoft.com...
>
>>I noticed that when I run my embedded DbIsam 2.46 app, both cpu's run up to
>>50% or slightly more. (Using AMD 4400 dual-core) If I stop the application
>>then both CPU's drop down to zero. How is it possible for an embedded
>>application (non-multi threaded) to use more than 1 cpu?
>
>
> This is something windows does with most applications. Don't worry.
>

I'm not so much worried, as bewildered.

I've never seen Windows do this with any of my other single threaded
apps or with any other embedded database for that matter. It's not
possible to split the processing of a single thread onto 2 or more
processors. Each thread must run on a single processor. So I'm not sure
why 2 processors are highly active (50% each)  when I run my DBISAM
application. I'm not complaining, if it can distribute the CPU load,
then great. I just want to play detective and see if I can explain
what's going on.

The only other thing it could be, is my AV program (or firewall)
scanning the disk access every time data is read/written from a DBISAM
file. But the task list does not show CPU activity by any other program
so I doubt this is happening.

Dave

Dave,

> It's not
> possible to split the processing of a single thread onto 2 or more
> processors. Each thread must run on a single processor.


The operating system can schedule its own threads onto any processor it
likes - particularly if they are quasi-asynchronous to the actual
application activity (maintaining the disk cache and swap file for example).


Eryk

Dave Harrison wrote:
> ...
> I've never seen Windows do this with any of my other single threaded
> apps or with any other embedded database for that matter. It's not
> possible to split the processing of a single thread onto 2 or more
> processors. Each thread must run on a single processor. So I'm not sure
> why 2 processors are highly active (50% each)  when I run my DBISAM
> application. I'm not complaining, if it can distribute the CPU load,
> then great. I just want to play detective and see if I can explain
> what's going on.
> ...

Could it be
[1]
.. one cpu runs a process
.. no load on the other cpu
[2]
Windows observes a) a load, and b) a free cpu
Windows transfers work to the other cpu
[3]
go to [2]

?

--
Aage J.

Aage Johansen wrote:
> Dave Harrison wrote:
>
>> ...
>> I've never seen Windows do this with any of my other single threaded
>> apps or with any other embedded database for that matter. It's not
>> possible to split the processing of a single thread onto 2 or more
>> processors. Each thread must run on a single processor. So I'm not
>> sure why 2 processors are highly active (50% each)  when I run my
>> DBISAM application. I'm not complaining, if it can distribute the CPU
>> load, then great. I just want to play detective and see if I can
>> explain what's going on.
>> ...
>
>
> Could it be
> [1]
> . one cpu runs a process
> . no load on the other cpu

No, I have a graph on both CPU's and they are both running at 50% as
soon as I start up my application. They both go to 0% when my
application stops.

> [2]
> Windows observes a) a load, and b) a free cpu
> Windows transfers work to the other cpu

Well yes it works this way if several processes/threads are running. But
my app is a single process and not multi-threaded. So how does it split
the work of 1 thread and run it on 2 processors. It's not possible. As
Eryk mentioned, maybe Windows is using CPU for disk cache?? There is no
other disk activity going on (I've monitored it) and no other process is
using CPU over 1-2% (I'm running ProcessExplorer). It's almost as if the
DBISAM engine is running on a different thread than the program (which
would be great if it could).

Dave

Dave,

<< Well yes it works this way if several processes/threads are running. But
my app is a single process and not multi-threaded. So how does it split the
work of 1 thread and run it on 2 processors. It's not possible. As Eryk
mentioned, maybe Windows is using CPU for disk cache?? There is no other
disk activity going on (I've monitored it) and no other process is using CPU
over 1-2% (I'm running ProcessExplorer). It's almost as if the DBISAM engine
is running on a different thread than the program (which would be great if
it could). >>

Doesn't the AMD dual-core processor make two processors act like one virtual
processor, kind of like the opposite of the Intel hyper-threading ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Dave Harrison wrote:
> Aage Johansen wrote:
>> Dave Harrison wrote:
>>
>>> ...
>>> I've never seen Windows do this with any of my other single threaded
>>> apps or with any other embedded database for that matter. It's not
>>> possible to split the processing of a single thread onto 2 or more
>>> processors. Each thread must run on a single processor. So I'm not
>>> sure why 2 processors are highly active (50% each)  when I run my
>>> DBISAM application. I'm not complaining, if it can distribute the CPU
>>> load, then great. I just want to play detective and see if I can
>>> explain what's going on.
>>> ...
>>
>>
>> Could it be
>> [1]
>> . one cpu runs a process
>> . no load on the other cpu
>
> No, I have a graph on both CPU's and they are both running at 50% as
> soon as I start up my application. They both go to 0% when my
> application stops.
>
>> [2]
>> Windows observes a) a load, and b) a free cpu
>> Windows transfers work to the other cpu
>
> Well yes it works this way if several processes/threads are running. But
> my app is a single process and not multi-threaded. So how does it split
> the work of 1 thread and run it on 2 processors. It's not possible. As
> Eryk mentioned, maybe Windows is using CPU for disk cache?? There is no
> other disk activity going on (I've monitored it) and no other process is
> using CPU over 1-2% (I'm running ProcessExplorer). It's almost as if the
> DBISAM engine is running on a different thread than the program (which
> would be great if it could).
>
> Dave

I still think this maight be an explanation.  The load is just that
single process/thread.  It bounces back and forth.  The resolution of
the display in Task Manager is too coarse to show the switching, just
the average (50% of each processor).

--
Aage J.

Aage Johansen wrote:

> I still think this maight be an explanation.  The load is just that
> single process/thread.  It bounces back and forth.  The resolution of
> the display in Task Manager is too coarse to show the switching, just
> the average (50% of each processor).
>

There is a graph for each processor (core) and when running *my* DBISAM
application, each processor runs around 50% (as if there were 2
threads). But if I use DbSys and pack the table, only 1 processor is
used (near 100%) and the other processor is near 15%. So maybe Eryk is
right and my application is somehow causing a Windows process to eat up
CPU on the second processor. There is plenty of memory available to its
not the page file. Only tables are used to there are no temp files from
queries. I'll find the cause eventually. Thanks for everyone who pitched
in.

Dave

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/