🚀 go-pugleaf

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)

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

Thanks,

Rob



> 
> First, your code doesn't really give enough information to go on -- it 
> doesn't show where the 'busy' flag is being tested, and doesn't provide any 
> context to make sense of the problem you are having.  You should probably 
> post a more complete example.
> 
> Second, if a Semaphore is needed, you can of course use the Win32 Semaphore 
> functions (CSemaphore is merely a wrapper around those functions), or you 
> can write your own semaphore class/wrapper.
> 
> Third, do you really need a semaphore?  Semaphores are typically used for 
> resource counting.  If you just need to synchronize access to data, a 
> critical section is simpler and faster.
> 
> - Dennis 
> 
>