Re: Interrupts handling in ADA

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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

Software interrupt, also called asynchronous system trap (AST) is a
different thing. What you had in mind is probably a software interrupt. 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

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

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.

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