Re: PPC 2003 Thread

You know that time-critical threads only run till completion, right? Not a
good choice for something like this. Try it without changing thread
priority and see what happens then.

Paul T.

"Channa" <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7F513D6A-A7D3-439A-81D5-0753702568A8@xxxxxxxxxxxxxxxx
> Hi Tobey,
>
> Here it is for you...
>
>
> // Create a read thread for reading data from the communication port. This
> section
> // of code is part of one of the clsSerialControl class memeber function
> // hReadThread and hCommPort are private member variables
> ....
> hReadThread = CreateThread (NULL, 0x100000, PortReadThread, this, 0,
> &dwThreadID);
> if(hReadThread == NULL)
> {
> // Could not create the read thread.
> }
> //Bump the thread priority up.
> SetThreadPriority(hReadThread, THREAD_PRIORITY_TIME_CRITICAL);
> ....
>
> DWORD WINAPI PortReadThread (LPVOID lpvoid)
> {
> BYTE Byte;
> DWORD dwBytesTransferred,dwCommModemStatus;
> BOOL bReadResult;
> COMSTAT cs;
> DWORD dwError;
>
> clsSerialControl *pNCP = (clsSerialControl *) lpvoid;
>
> while (pNCP->hCommPort != INVALID_HANDLE_VALUE)
> {
> // Specify a set of events to be monitored for the port.
> SetCommMask (pNCP->hCommPort, EV_RXCHAR|EV_ERR);
>
> // Wait for an event to occur for the port.
> if (WaitCommEvent(pNCP->hCommPort, &dwCommModemStatus, 0) != 0)
> {
> if (dwCommModemStatus & EV_RXCHAR)
> {
> // Loop for waiting for the data.
> do
> {
> // Read the data from the serial port.
> bReadResult = ReadFile(pNCP->hCommPort, &Byte, 1,
> &dwBytesTransferred, 0);
> if(bReadResult && (dwBytesTransferred == 1))
> pNCP->gbInputBuffer.PutByte(Byte);
> }while(bReadResult && (dwBytesTransferred == 1));
> }
> else
> {
> ClearCommError(pNCP->hCommPort,&dwError,&cs);
> }
> }
> }
>
> ExitThread(0);
> return 0;
> }
>
> BOOL clsSerialControl::CloseCommPort()
> {
> DWORD dwError;
> HANDLE hClosePort;
>
> if (hCommPort != INVALID_HANDLE_VALUE)
> {
> hClosePort = hCommPort;
> hCommPort = INVALID_HANDLE_VALUE;
>
> // Close the communication port.
> if (!CloseHandle (hClosePort))
> {
> dwError = GetLastError ();
> return FALSE;
> }
> WaitForSingleObject(hReadThread, INFINITE);
> }
> return TRUE;
> }
>
> Thanks,
> -Channa.
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> At a guess, because you're waiting on the wrong handle. Show us a 30
>> line
>> or less sample, including the thread procedure, which demonstrates the
>> problem.
>>
>> Paul T.
>>
>> "Channa" <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:F24C0CD4-49AA-4C6F-BBF9-2A5A39AD1A67@xxxxxxxxxxxxxxxx
>> > Hi,
>> >
>> > I have an app created originally for PPC 2002 using eVC++ v3.0 and,
>> > it
>> > has been migrated to PPC 2003 platform using eVC++ v4.0.
>> >
>> > I have been noticing some odd behaviour since recently, and thought
>> > of
>> > asking if anybody else have experienced the same and worked around
>> > already? I
>> > have a separate thread reading the COM port. I am noticing that
>> > although
>> > this
>> > thread exit normally, the main process do not get signaled state (using
>> > WaitForSingleObject INFINITEly)!
>> >
>> > I did trace using Kernel Tracker tool and noticed that the two
>> > threads
>> > (main- and the COM-port-reading-thread) got blocked. I used to use
>> > "return"
>> > for exiting the COM port reading thread. So, I changed it to
>> > ExitThread(),
>> > and now, the COM port reading thread get terminated but the main
>> > process
>> > do
>> > not get signaled and the Kernel Tracker tool shows that my main thread
>> > is
>> > still being blocked. I have no idea is to why?
>> >
>> > Any input would be appreciated.
>> > Thanks in advance,
>> > -Channa.
>> >
>>
>>
>>


.