Re: Locking a COM port

nobody_at_noplace.not
Date: 07/07/04 

Date: Wed, 07 Jul 2004 10:30:43 -0400

On 07 Jul 2004 07:36:53 GMT, alanglloyd@aol.com (AlanGLLoyd) wrote:

>I appreciate the asynchronous natiure of overlapped files, but at which level
>and where does any activity surrounding an overlapped file become synchronous.
>At any CPU atomic operation, or at some higher point (which I don't know),
>possibly above the OS level and in the application. How can I (if I can)
>control the asynchronicity of any operation. That's where the fuzziness of my
>understanding lies.

Ok... it becomes synchronous at the driver level where the driver must
manage it's own data stream as a single entity to be sent to a device.

The most common example of this is the print queue. Programs add documents
to the queue, and then go on about their business... the printer driver is
responsible for getting the queued data out to the printer without screwing
it up. (OK that's oversimplification, but it demonstrates the concept)

For you as a programmer the difference is quite simple... when you do not
use overlapped i/o the procedure is going to wait for the operation to
complete before it returns to your program. If you are using overlapped,
the operation will go off, stuff the data in a buffer someplace, tell the
device driver about it and immediately return control to your program
*without waiting for the I/O operation to complete*.

Lets say you are sending lines of text to a printer on a serial port...

Back in the good ole DOS days, you would write a subroutine that would
monitor CTS and send bytes until the printer toggled CTS to signal buffer
full. You would then wait until CTS returned high again and begin sending
more data... wait, send, wait, send... and all the while your program is
stalled waiting for this to finish.

In Windows machines this has been moved to the device driver which sends the
text from a reserved memory buffer. All you as a programmer have to do is
put the text in the buffer and inform the driver it's there... which is done
by WriteFile. As far as we are concerned the operation is complete when the
data is placed in the memory buffer, the driver takes over from there and
finishes the job for us. This is a necessity in multitasking environments
if we don't want entire networks brought to their knees by an empty paper
tray.

Without Overlapped... you use write file to put data into the buffer, and it
will wait for the driver to dispose of the data before returning to your
program.

With overlapped... you use writefile to put data into the buffer and it
returns immediately to your program trusting the driver will adequately
dispose of the data. It queues the data.

As you can imagine using overlapped and trusting device drivers can
significantly increase the performance of your programs... but it also comes
with something of a price...

You have to be very careful about doing some things... For example:

Without overlapped...

Writefile, prepare data, writefile, prepare data, writefile... close port.

This is safe to do because writefile doesn't return until the data is
handled.

With overlapped...

Writefile, prepare data, writefile, prepare data, writefile... wait for data
to be handled... close port.

The extra step is required because writefile didn't wait around for the IO
operation to complete itself... now you have data in the buffers that is not
handled, closing the port immediately after the last writefile would
truncate the data stream before everything is sent.

This wait-for-completion process is acommplished by Signals. Signals let you
synchronize operations to events. Rather than checking CTS on the port, like
we did on DOS, now we set up a signal that goes on when the data buffer is
empty. Check in the Windows SDK for a more or less detailed explanation.

-----
Laura

Relevant Pages

  • Re: Serial Communications - Lost Event
    ... "Completion of write" is a moment when all data from the app buffer is ... The driver can keep the data in its internal buffer ... > serial port monitoring and test applications. ... > of a serial port means when all of the data has been transfered. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Reading COM1 with php-win
    ... > loop waiting for data on the COM port to get data off it. ... buffer built in. ... driver. ... Yes, you can use the com activex object, and it does help. ...
    (comp.lang.php)
  • Re: Reading COM1 with php-win
    ... > loop waiting for data on the COM port to get data off it. ... the serial port hardware itself has a 16 byte buffer built in. ... Your program doesn't talk to the chip itself; it talks to the driver (through Windows). ...
    (comp.lang.php)
  • Re: Difference between synchronous and asynchronous operation/calls (NDISPROT)
    ... The main problem with synchronous operation/calls seems to be the lack of buffers for the driver to store data into. ... Each "read call" supplies the driver with a buffer and optionally a completion routine so that the driver can inform the application when the requested operation is/was done. ... However it seems the current windows/driver design does some copies as well? ...
    (microsoft.public.development.device.drivers)
  • Re: Degradation of TCP connection
    ... Gigabit ethernet. ... D card's data buffer can only hold about 64K samples worth of data ... link you posted is for an older version of VxWorks that used a BSD- ... but a bug in the ethernet driver. ...
    (comp.os.vxworks)