🚀 go-pugleaf

Hi Dennis,

Wow! I appreciate the insight.

The parent thread is my main application thread, TApplication with TCustomForm,
etc. My understanding of this process loop is:

while (Message != WM_CLOSE)
{
	GetMessage()
	ProcessMessage()
}

ie, the standard windows thread. So, I spawn a thread in my
TShellForm::FormCreate() function...


	// spawn thread for advanced grab/display routines
	hThread = (HANDLE)BeginThread(THREAD_PRIORITY_NORMAL,
				      0, VideoGrabbingThread,
				      this, 0, ThreadID);

	// set thread priority
	SetThreadPriority(hThread, THREAD_PRIORITY_LOWEST);


This is the only other thread I've got running, besides a TTimer here and there
for GUI countdowns... nothing that should impede my video loop.

It just seems like when the video is streaming, the mouse is unresponsive for a
second or 2, every 5-10 seconds or so. Reminds me of my college days and the
notorious lag monster!


I guess I need to do some more research on the dual-processor and multi-threaded
semaphore environment. This is certainly outside my expertise. As you guessed,
I've never used a dual-processor, nor have we delivered one, nor has my program
been run on one to the best of my knowledge.


Thanks again! I really appreciate the advice!

Rob


Any advice from you multi-thread guys? I'm kinda flyin' blind here. :)




Dennis Jones wrote:
> "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 
> 
>