Re: Looking for implementation idea

[Thomas Handler <thandler@systems.at>]

Niklas,

many thanks for your reply.

Niklas Holsti wrote:
> 
> Thomas Handler wrote:
> >
> > Hi everybody!
> >
> > I'm trying to migrate a bundle of applications to Ada95 (running GNAT
> > and Intel-Linux).
> > The problem I'm suffering from at the moment is that most of the apps
> > are heavy I/O bounded and the first one I'm gonna touch has to control
> > typically around 100 devices via serial ports and about 40-50 socket
> > connections.
> (snip)
> > My idea was to implement a kind of IO-Manager that is responsible for
> > doing the central select() call, since FSU Threads block all threads on
> > systems calls.
> 
> If your application is really I/O *bound*, perhaps the additional CPU
> load of native thread switching could be tolerated. Depends on your
> response time requirements, of course.

This is something I really have to think of, unfortunately I have no way
to make any tests at the moment because I'm awaiting my 100 serial port
hardware. But I guess you're completely right with your hint - since
serial ports aren't that CPU itensive peripherals (they will be driven
with 38400 baud).
But there exist some other problems I have to cope with. As an example I
have the problem that I have to shut down my application in a friendly
manner so that no file corruption within the files of the used database
can occur. Therefore it's also a problem that I can't simply abort the
OS-Select call via ATC, so I came up with the solution of opening a pipe
as a separate communication channel to signal that kind of event. But
doing this within 100+ tasks and OS_Selects seems rather awkward (though
I have to admit that the solution via pipe itself isn't that pretty ;-)
- that's why I'm not sure if I like using it as a replacement for the
ATC to abort the select when neccessary.

> 
> I don't understand: if the OS_Select blocks all tasks (threads), where
> does the Event.Wait signal come from? Or is the "then" branch only
> abortable in the "preparing" and "operate" parts?

It's right, when using FSU lib I suggest that Event.Wait will come from
nowhere, but what I'm trying is to implement as close to the RM as
possible and since the RM doesn't guarantee that a blocking OS call
doesn't block all other tasks. So the  Event.Wait is for the case when
the other tasks aren't blocked like when using LinuxThreads.

> 
> > But after thinking how Ada (or more exactly GNAT) implements ATC I saw
> > some problems upcoming and did some tests on the above loop. This tests
> > did interrupt OS_Select() very often and I got the expected result -
> > after some hundred interrupts my system was unable to handle any
> > OS_Select even in a new context (i.e. after a logout and a new login),
> > so it seemed the kernel has run out of ressources...
> 
> That problem sounds serious enough to report as a bug, either to ACT
> or FSU.
It seems obvious to me, just imagine what will happen, when you abort a
call that has requested dynamic memory? I guess this memory will be
lost.
The only thing I can't understand is that ATC doesn't fit into the
safety approach of Ada, since you can do rather nasty things the easy
way without having any hint (if you don't count on your mistakes you
made in the past - that's where experience comes from ;-)

> 
> On the general problem, I usually dislike centralising I/O in the
> way you plan -- it's a single-threading, select()-style approach
> which is not optimal for a more concurrent tasking design. Perhaps
> the group could suggest some other structure if we knew a little more
> about the data flow topology of your application.
I agree but I think it's easier to control from point of view of the
application.
The data flow of the application isn't that easy to describe, the
application will do access control. The devices are ticket readers that
can read barcodes and contactless RFID Tags. These readers are mounted
on turnstiles and both (the reader and the turnstile) are connected to
the host via a single RS-485 line. One host will be able to control
about 128 such combinations. 
The problem is that the barcodes can be free running and the RFID can
not since several RFID readers within one area are disturbing each other
- so I have to use some form of synchronisation. Maybe this short
overview gives a hint?

> 
> In another thread discussing FSU vs. native Linux threads, a claim
> was made that FSU threads support per-thread blocking on the most
> common I/O calls -- read() and write() were mentioned, I think.
> This could be another reason to avoid the select().
Then I must have missed something. Is it definitely this way that a call
to OS read() (i.e. a binding to the read() of theC library) issues per
thread blocking?
If this is true I would have to change my mind.

> 
> If you stick with select(), I suggest replacing Event.Wait with an
> additional internal port (file descriptor) that is used by tasks
> contacting the I/O manager and included in the select(). In this
> way, the select() would never be aborted by ATC, and thus the
> OS resources should not leak. The internal port doesn't need to
> carry any data; it could be used just to terminate the select(),
> with some real Ada mechanism used to communicate between the
> contacting task and the I/O manager, once the latter is awake.
I have mentioned this way already above, thank you.

> 
> Your application sounds a good match for Ada tasking. Please post
> on your progress.
> 
> - Niklas

Since I got that response from that group I assume that there are some
people interested in such information (?) and so I will post my
progress.

Once again many thanks for your reply.

Ciao,
  Thomas Handler