Re: Interrupts handling in ADA

[Ada BRL <ada.brl.2011@gmail.com>]

On 11 Dic, 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 10 Dec 2011 12:43:58 -0800 (PST), Ada @ BRL wrote:
> > The environment of ADA applcation is:
> > I have 4 tasks that execute at the same time:
> > one is the main task,
> > the other three execute a "read" from network (socket) function inside
> > their bodies (on the other side there's the C/C++ application with 3
> > network sockets).
> > [I decided to use the sockets instead of dll/lib import because this approach hasn't worked... =( ]
>
> What dll import has to do with sockets, except that sockets usually are
> provided by a library?

I would have liked to use dll import to exchange data between C stuff
and Ada program instead of using two programs (C and Ada)
communicating through sockets...
but the dll import hasn't worked even with dummy and correct dll...
So, in order to overcome the problem, I've decided to use sockets.

>
> > I want that when new data is available on one or more socket threads, this
> > / these threads somehow notify the main thread that data is arrived and
> > then safely send the data to it.
>
> If you have many sockets, you should probably use select on them rather
> than blocking calls from many tasks. The maximal number of tasks supported
> by the OS is usually much lower than the maximal number of sockets.

I have a maximum of 5 sockets so I guess there will be no problems
onto the OS side...I hope so =).

What's the "select" you have just mentioned?

>
> > I've thought to use the interrupts...
>
> Interrupt in Ada is meant more like "hardware interrupt." It is possible
> but unlikely that your network stack generates such interrupts or that you
> could have an access to them under the OS you are running.

Ok, now I've figured out that the Ada interrupts are only HW and not
SW.
The software interrupts are implemented with entry / accept paradigm
(like events in C++? ).


>
> Software interrupt, also called asynchronous system trap (AST) is a
> different thing. What you had in mind is probably a software interrupt.


YES!


> The corresponding Ada mechanism is "Asynchronous Transfer of Control" (ATC).
> But there are much better ways.
>
> > because I haven't found any
> > references about the use of "events" in ADA.
>
> Events are low-level synchronization objects easily implemented using Ada
> protected objects, e.g.:
>
> http://www.dmitry-kazakov.de/ada/components.htm#Events
>
> Events are rarely used in Ada, because for inter task communication you
> have higher-level means.
>
> > I've thought to attach three different handler of interrupts into the main
> > task and then to generate the interrupt from the socket task with
>
> There are many ways to implement things like this:
>
> 1. One task + socket select

See above: what's select?

>
> 2. "Monitor": multiple socket readers do rendezvous to the main task, which
> accept the rendezvous.

In rendez-vous paradigm, is the main task forced to wait for ALL the
socket tasks or only for a subset of them?
Eg: only socket #2 has received some data, can the main task execute
or does it have to wait also for the other sockets?

>
> 3. "Queue": socket readers enqueue some data (the queue is implemented
> using a protected object). Other tasks (there could be many) dequeue data
> and do something meaningful with them. There are many kinds of queues for
> different purposes and of different behavior.
>
> 4. Single rank co-workers. Each socket reader processes data by themselves.
> In order to interlock processing there is a semaphore/mutex (implemented by
> a protected object), which is seized when processing starts and released
> afterwards.


In your opinion, what's the most effective and at the same time
simplest way to sort out my problem?
Simon Wright has posted an example of Protected queue and entry /
accept statements and it seems to be simple but effective as well.

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de