Board index » cppbuilder » Multi-Thread Processing on Dual-Core CPU

Multi-Thread Processing on Dual-Core CPU


2007-03-14 11:51:18 PM
cppbuilder68
Hi Jon,
Yep, that did the trick. Makes sense, I suppose if you ignore the "MM_TEXT"
description??? ;)
As this thread has been incredibly helpful for my understanding of multi-thread
parallel processing, I'd like to throw another log on the fire....
I'm now realizing how little I know about multi-thread processing as my other
threads in my program are crashing out. For example, my commport listening
thread causes a program fault when I change the value of the indexing variable.
When I set RXSize to 0 in my main thread/process, the fault occurs, I assume
because it's fighting with the ReadFile() line below. This code has no
semaphores in it at all. If I place simple bool variables like 'busy' and
'waiting' into the code, will I run into the same problem, accessing the bool
variables from both sides at once? Is this a good case for the Win32 Semaphore
functions? Are they overkill for this little thing? My experience is very
limited because I never had this problem with single-processor systems, and of
course this code functions with no problem on my older machines. But the
dual-core.... no dice. :(
Thanks,
Rob
_____________________________________________________________
void CommPortClass::TransferThread()
{
// log event
Global_UpdateStatusPrivate(String("entering ") + __FUNC__ + "()...");
// set semiphore
ThreadTerminated = false;
ThreadFinished = false;
// listen for incoming data, transfer outgoing data as needed
while (!ThreadTerminated)
{
// number of bytes read from port
DWORD BytesRead;
// read from port in case data is coming in
ReadFile(hComm, &(RXBuffer[RXSize]),
RXBufferLength - RXSize, BytesRead, NULL);
// check for incoming data
if (BytesRead)
{
// increase buffer count to reflect presence of new data
RXSize += BytesRead;
}
// check for data to write
if (TXSize)
{
// number of bytes written to port
DWORD BytesOut;
// write data to commport
::WriteFile(hComm, TXBuffer, TXSize, &BytesOut, NULL);
// decrement buffer count to reflect transfer of data
TXSize -= BytesOut;
}
}
// clear semaphore - allow class to exit
ThreadFinished = true;
// log event
Global_UpdateStatusPrivate(String("exiting ") + __FUNC__ + "()...");
}
//---------------------------------------------------------------------------
 
 

Re:Multi-Thread Processing on Dual-Core CPU

Robert G. Hoover wrote:
Quote
Yep, that did the trick. Makes sense, I suppose if you ignore the
"MM_TEXT"
description??? ;)
Good :-)
Quote
I'm now realizing how little I know about multi-thread processing as my
other
threads in my program are crashing out. For example, my commport listening
thread causes a program fault when I change the value of the indexing
variable.
When I set RXSize to 0 in my main thread/process, the fault occurs, I
assume
because it's fighting with the ReadFile() line below.
Possibly. I would use a critical section for that code.
Quote
This code has no semaphores in it at all. If I place simple bool variables
like
'busy' and 'waiting' into the code, will I run into the same problem,
accessing the
bool variables from both sides at once?
Possibly. I personally wouldn't take any risks, and would just use
semaphores, critical sections or events here.
Quote
Is this a good case for the Win32 Semaphore
functions? Are they overkill for this little thing?
I would say it is a good case for the Win32 syncronization functions. You
can use critical sections, events or semaphores, depending on what you need
to synchronize.
Read the topics in this page for some more detail on the thread
syncronization functions that Windows has:
msdn2.microsoft.com/en-us/library/ms686353.aspx
HTH
Jon
 

Re:Multi-Thread Processing on Dual-Core CPU

Robert G. Hoover wrote:
Quote
When I set RXSize to 0 in my main thread/process, the fault occurs, I assume
because it's fighting with the ReadFile() line below.
That doesn't sound like a very good idea.
For example:
Quote
ReadFile(hComm, &(RXBuffer[RXSize]),
RXSize is 1000
Start reading into RxBuffer[ 1000 ];
Main resets RXSize to 0
Read finishes 100 bytes
Quote
if (BytesRead)
{ RXSize += BytesRead;
RXSize is 100;
100 bytes are at RxBuffer[ 1000 ];
Who remembers those bytes?
Next read will take place at RxBuffer[100], not 0.
Other than CriticalSections, a nice way to keep order is to setup
pairs of variables. V1 is read/writable by main, but read-only by
thread. V2 is read-only by main but read/writable by thread.
In this case, main would write I want you to read N bytes, and I have
read X bytes from your buffer.
Thread would write I have Y bytes avilable in the buffer at location
Z.
Likewise for TXSize. You have 2 threads modifying it.
 

{smallsort}