Re: Palatable Windows IO using Ada

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:o2i2brhcp49x$.1lmgnwrqgqzf7$.dlg@xxxxxxxxxxxxx
On Sun, 9 Apr 2006 06:50:23 -0700, Steve wrote:
[snip]

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

So did I. On the systems I have used there have been systems calls "read
until character or timeout" or at least a mechnism of implementing that
functionality.

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

[snip]

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.


I prefer two threads as well. It is my understanding that the only way to
do this on NT is using overlapped I/O. I have this working in my high level
interface to NT's serial port.

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.


Sure you can. You just have to be explicit about how concurrency is
handled, and can't take anything for granted. This leads to platform
dependent code, which I usually handle by implementing a high level
interface inside of a platform dependent package implementation.

I believe that programming languages that handle concurrency are the
exception rather than the rule. Which is one of the reasons I prefer Ada
over those languages, but it certainly doesn't keep multi-tasking programs
from being implemented in those languages.

The majority of development I have done in the past has not been in Ada.
When developing systems non-Ada systems I always face an OS learning curve
and a programming language learning curve. The programming language
learning curve is to learn the local dialect of the language, since the
standard language doesn't include everything needed to do concurrent work.

Ada covers enough bases I only have to learn a small part of working with
the OS. This comes back to my claim that you can develop a system in almost
any programming language, given enough time and money... but if you want to
minimize either, use Ada.

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.

[snip]

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.

I think this is the case for networked communication, but not for serial
communication.

Steve
(The Duck)


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


.