Need faster time slice for threaded MFC application

[Andy Devine]

Env : VC++ V6, NT4 sp5

Hi all,
I'm writing a Serial comms app that creates a seperate polling thread (using
CWinThread::AfxBeginThread).
This sets a worker thread function to read the receive buffer continuously
(endless 'for' loop until a boolean flag causes a 'break'). If I transmit
packets (of 30 bytes) every 31 milliseconds (using a seperate app with an
OnTimer event) it will read every byte sent to it. As soon as I try sending
it packets every 30 milliseconds the receive buffer fills up and I start to
loose frames.

I have tried commenting out all functionality from the worker thread so all
it does is read 100 bytes from the receive buffer for each iteration.
Increasing the amount of characters it reads from the port each time has not
helped.

The comms is running at 115.2K, 8 databits, 1 start

My thoughts at the moment is that Windows is not 'time slicing' my thread
quick enough to receive packets sent to it quicker than at 31ms gap. I have
tried setting the priority of the thread to the highest as well.

I would be very grateful for any thoughts anyone may have as to the cure (if
any) for this,

cheers,
Andy

[Joseph M. Newcomer]

You can't really get a "faster timeslice". When a thread is blocked on
I/O, and the I/O completes, the thread is given a one-time-slice
priority boost which allows it to preempt the running thread,
providing the running thread is of lower priority. However, in NT (and
perhaps in Win9x), there are very high priority system threads, such
as file system threads, that can run arbitrarily long, and your
priority boost won;t be high enough to preempt them. NT is not a
realtime system, and writing code that critically depends upon the
thread being scheduled will ultimately lead to failures.

If I were doing this, I'd allocate an input buffer of a massively huge
number of bytes, and I'd probably try to use asynchronous I/O with
several ReadFile operations pending at once, which puts the context
swap of the buffers down into the device driver, which makes it very
fast.

Essentially, the problem is not the timeslice, but what we would call
latency, the time between the receipt of an interrupt and the time the
thread that can run as a consequence of the I/O completion will
actually get control. This can be 200-400ms in many cases. Thus having
several ReadFile operations queued up will help with the high data
rates you are trying to run at.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

[Andy Devine]

Thanks very much for the info.
I am going to try your method now.

cheers,
Andy

Joseph M. Newcomer <newc...@flounder.com> wrote in message
news:y2+9OOGYsKWRWg...@4ax.com...

[Hans-Martin Brændmose Jensen]

Make sure you read *all* data in the input buffer on every read and not just
one character at a time. Then even a normal priority thread should be able
to get all data without loosing frames (assuming no other processing
intensive programs are runnning at the same time, of course). For more
inspiration look at the MS example MTTY:

http://msdn.microsoft.com/library/techart/msdn_serial.htm

Hans-M.

"Andy Devine" <andrew...@gecm.com> wrote in message
news:38be...@pull.gecm.com...