🚀 go-pugleaf

"Robert G. Hoover" <not.a.real.address@anywhere.sorry> wrote in message 
news:45f583fb$1@newsgroups.borland.com...
> Hi Dennis,
>
> You know, I've been asking myself the same (#3) question. The 'busy' flag 
> is not
> being tested in my main process at all until the point of termination. 
> (Wait
> until !busy before terminating parent process)

Is your "parent process" a thread, separate from the thread that is doing 
the work?  What is your parent process/thread doing to wait?  Is it in a 
loop, like this:

while (!busy)
    ;  // do nothing

That would be very processor intensive, though it would be every bit as much 
of a problem on a single processor as on a dual (if not more so).

If you are having serious problems with a dual processor but none on a 
single processor, it could indicate a more fundamental problem with thread 
synchronization, as there are some thread-related problems that will not 
manifest themselves in a single processor environment (which is not true 
multi-tasking) but will blow up in a dual processor environment due to race 
conditions, dead-lock, etc.


> So, is my problem semaphore-related? Or rather processor related? I can't
> imagine implementing the Win32 Semaphore functions and seeing any 
> different
> results.

I can't either.  Given your explanation of how you are using 'busy' and 
depending on how you are waiting on it, I would expect the program to behave 
badly (or marginally) on a single processor, but better (though still not 
optimally) on a dual.  Using a thread synchronization object in your code 
would be a good idea regardless, and given what little I know so far, a 
semaphore might not be such a bad choice after all.


> My Borland BDS 2006 (C++ Builder) is compiling my program the same way
> as always, before this new chip was introduced to the market. Is it 
> possible
> that the compiler is not compiling optimally for this new chip? Can BDS be 
> set
> to compile differently for this dual-core chip?

I doubt it.


> Can I use 1 half of the
> processor for my main application thread and the 2nd half for my video 
> thread so
> that they are executed in true parallel?

I don't know -- that is a good question.  I do not have a dual processor 
system, so I've never experienced it myself, but I've always sort of assumed 
that if you were using multiple threads, that the OS would/may decide to 
distribute a processes threads across the CPU's for you.  Perhaps someone 
with more mulit-processor knowledge than I will jump in here.


> This certainly seems to be a problem
> related to the processor itself as that's the only thing that has changed. 
> I've
> been compiling in Borland for near 14 years, MANY different computers,
> processors, peripherals, etc, and never seen this kind of behavior...

And you've probably never had an app run on a dual-core/dual-processor 
machine before either -- it's a whole different kind of animal when it comes 
to multi-threading.  I have an app that runs on single- and dual-processor 
machines, and I was initially a little concerned with whether my app would 
handle multi-processor machines, but so far I haven't had any reports of 
problems.  Maybe I got lucky, or maybe I wrote my thread synchronzation 
correctly the first time -- the point is, you might never have a problem 
until multiple processors come into play.

- Dennis