Re: Palatable Windows IO using Ada

On Sun, 9 Apr 2006 06:50:23 -0700, Steve wrote:

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.

How would you tell that to the driver? Do you mean a true driver here or
merely a program that uses an OS serial driver? I meant the later. Talking
about drivers, you are absolutely right. Interrupts are very expensive on
wintel platform. I had to redesign one driver (an ISA transputer link
driver) for a similar reason. The card produced an interrupt per byte at up
to 1Mbaud...

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

I prefer two threads, one does blocking read (incoming bytes stream),
another blocking write (outgoing packets), it works well. Overlapped I/O is
too clumsy, then the read buffer cannot be accessed anyway when the
operation is pending.

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.

How can you do it language neutral? The problem is that asynchronous I/O
inherently requires concurrency. If the language does not support
concurrency, you simply cannot comprehensively describe what's going on.

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.

I started on RSX-11 and VAX-11, so to me it was a shock to see for the
first time how many processes were running on an idle Unix machine. Slowly
I adapted to the idea that each mouse button needs a separate process to
deal with (:-)) Windows is somewhere between. It is unfair to blame alone
Microsoft for all mess. It was Unix first, which destroyed the market of
operating systems. We have what we have deserved.

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...

Once I managed to install Windows NT 4.0 on a 486DX 66MHz / 12Mb. It took
about one day. The system booted in 10 minutes or so. I still remember VMS,
which served 6 interactive users having 4Mb memory. It had DEC Ada too!
(:-))

it's been long enough that I can't remember). On those machines
the time difference was more significant.

Actually it worked well on a Pentium 133 under Windows NT 4.0. COM port
isn't fast enough to break it down. In fact, in one case we had to slow
down the PC side, because the device crashed when PC had written too fast.

I'm too lazy to look into Kernel32.dll, but I guess, that an ReadFile call
isn't that expensive. I suppose that there is an OS-allocated buffer in the
process space, so ReadFile does nothing extraordinary. Because the input is
buffered, it makes little sense to do it again.

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