Re: Palatable Windows IO using Ada

["Steve" <nospam_steved94@comcast.net>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:14sfx2j059hst$.1x6sfev1savpw.dlg@40tude.net...
> 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