Re: Palatable Windows IO using Ada

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:14sfx2j059hst$.1x6sfev1savpw.dlg@xxxxxxxxxxxxx
On Fri, 7 Apr 2006 19:07:35 -0700, Steve wrote:

[snip]

This is a higher level protocol. The point is that when the OS does not
natively support a device-specific application layer protocol, and it
normally does not, then there is no other place to do it as in the
application. So the communication item becomes one byte. Blocking for more
than one byte at once is looking for troubles. Even if the protocol has
things like bytes counts. Practically none of multiple serial devices we
dealt with worked according to the specification. Using bytes stream full
duplex communication model has saved us a lot of time, because we could
easily adapt our software and overcome bugs in the hardware.


It is interesting the opinions that are formed based on one's experiences.
Mine is at least in part formed because in the past I have had to rewrite
drivers that handled one character at a time to process as many as possible
at a time due to performance issues.

In one case, when communicating with an Allen Bradley PLC using DF1
protocol, I found that the driver that handled one character at a time used
up a significant part of the available CPU time. Enough that the computer
was observed to be very sluggish.

The DF1 protocol uses markers (DLE) to mark key locations in the data
stream. By using a "read until character" function instead of reading one
character at a time, the CPU overhead was significantly reduced, and the
system was no longer sluggish.

Most of the applications I have worked on make heavy use of the CPU and are
time critical (but not safety critical). Minimizing the processor overhead
used by communication is often a goal.

Windows ReadFile isn't always blocking, it can be asynchronous, see
"overlapping" I/O in MSDN description of ReadFile.

I've been through the windows overlapped I/O for serial communications.
In
my opinion it's a royal pain in the ass.

Yes. In my opinion it is overkill to use overlapped I/O for serial
connections. Though if you have 1000 devices to handle simultaneously,
there might be no other choice. In RSX and VAX, where the idea of
asynchronous I/O seems was borrowed from, it worked well. I also think
that
overlapped I/O and asynchronous system trap could nicely fit to Ada's
protected objects. The interface to overlapped I/O is so clumsy because
API
is in C, it should be in Ada! (:-))

On NT/XP for full duplex communication, you really have two choices:
Use non-blocking I/O (poll)
Use overlapped I/O

The clumsy interface has no relation to the choice of language of the API.
And it shouldn't. It is based on the design of the driver. In the good (or
bad?) old days, the OS interfaces used to be described in a language neutral
manner... as it should be.

When I had to make duplex serial communications work right on NT, I found an
article descrbing how great it was that NT could do overlapped I/O, and how
it was something new and wonderful. I was left with the impression that the
developer had only done the D part of R&D and thought this was a great new
feature. I found it to be a clumsy feature that was working around a poor
driver implementation. I had the same impression when Microsoft "invented"
multi-threaded programming... after I had already been using multi-tasking
systems for years.

[snip]
Windows does buffering in background, so it isn't that wasteful. The
knowledge of how many items can be read at once depends solely on the
application.

You're kidding... right? Every transaction with a driver in NT involves
a
significant amount of overhead. If you read one character at a time
you're
incurring the overhead for each character.

I didn't saw any significant difference when using synchronous vs.
asynchronous read for serial devices. Taking into account serial
connection
speed I doubt one could notice it. A more interesting case is socket I/O.
Our commercial software reads from sockets using 1 byte buffer and
blocking
read. Recently we did elaborated time measurements under Windows XP and
Server 2003 for stream uni- and multicast sockets. It was all but easy,
because of quite flawed design of Windows time services. But that's a
different story. Anyway, our experiments have shown that the bottleneck
wasn't communication. We tested publisher / subscriber services of our
product and have noticed that the communication layer by margin
outperforms
other (local) parts. Roughly, global mutexes and context switches are much
worse than I/O APIs, even if the former are used per data block and the
later per byte.


Since you're using Windows XP and Server 2003, you're probably using recent
hardware, which is fast enough that you may not see an overall time
difference. If you use a high resolution performance counter to do you're
timing you are much more likely to find a difference.

I started working with networking on NT on Pentium 166 machines (or
slower... it's been long enough that I can't remember). On those machines
the time difference was more significant.

Steve
(The Duck)

If you have a nice library that buffers things for you, you don't have to
worry about it. But for serial I/O you'll have to build that on top of
the
call to ReadFile.

There is no other choice. The transport layer of serial connection is byte
stream. It is a medical fact. (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


.

Relevant Pages

  • Re: Cohens paper on byte order
    ... > representation of values once we're inside the I/O ... a chunk of bits of size 8 is simply an ... is not singularly 'specific' to AES. ... little knowledge about transmission protocol. ...
    (sci.crypt)
  • Re: Palatable Windows IO using Ada
    ... have seen for the Win32 API simply export the ReadFile and ReadFileEx ... So the communication item becomes one byte. ... "overlapping" I/O in MSDN description of ReadFile. ... If you read one character at a time you're ...
    (comp.lang.ada)
  • Re: Common Interface to I/O
    ... You may want to look at using a factory pattern to encapsulate the creation ... For my project I have a class called Protocol, ... > to two different I/O. ...
    (comp.software.patterns)
  • Re: Asynch COM under Win98
    ... I am mostly not a Windows programmer however about 3 years ago I wrote an MFC ... GUI control program that did serial I/O and our objective was to be compatible ... another view states that serial overlapped I/O works in W9X but non-serial ...
    (microsoft.public.win32.programmer.kernel)
  • Re: LsaEnumerateAccountsWithUserRight failed with "Overlapped I/O operation is in progress"
    ... Don't use GetLastError() with them (unless the function ... LSA is telling you that it is has finished the enumeration. ... it says "Overlapped I/O operation is in progress.". ... Or is there a way to disable overlapped I/O and use synchnonized I/O ...
    (microsoft.public.platformsdk.security)