Re: Palatable Windows IO using Ada

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

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