Re: Interrupts handling in ADA

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 11-12-10 22:43 , Ada @ BRL wrote:
> Hello,
> I'm an Erasmus student at the University of Bristol - UK and I'm
> carrying out the work for my master thesis in Computer Engineering.
>
> I'm programming a multithreading application in C / C++ and ADA.
> The latter is a completely new language for me...
>
> 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... =( ]
>
> 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.
>
> I've thought to use the interrupts...because I haven't found any references
> about the use of "events" in ADA.
> 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
> ada.interrupts.signal.generate_interrupt.
> Socket 1 will generate interrupt #1, socket 2 ->  interrupt #2 and so on.
>
> May you tell me please if this is the right way to face the problem?

I wouldn't say so -- better use the Ada features intended for 
task-to-task communication. There are basically two such features:

- rendezvous, an older method, and
- protected objects, a newer method.

The rendezvous method resembles sockets, in a way: one task acts as a 
server and exports an "entry" that other client tasks can call. When the 
server task is ready to accept a call on an entry, it executes an 
"accept" statement; typically, the accept statement suspends the server 
task until some client task calls the entry. Symmetrically, if a client 
task calls the entry, and the server is not waiting in an accept 
statement for that entry, the client task is suspended until the server 
accepts the call. (You can also avoid these suspension, if you want.) 
When the server is accepting, and some client is calling, the 
"rendezvous" (French for "meeting") happens, and the statements defined 
for the entry (in the accept statement) are executed. The parameters of 
the entry can transfer data from client to server and server to client. 
When the entry statements are completed, the rendezvous ends and both 
tasks continue in parallel again.

In your case, the main task would act as the server task and the other 
three tasks would be client tasks. If the data ("events") that the three 
client tasks send to the main task are of different types, the main task 
could export three different entries, one for each client task, with the 
corresponding types of parameters. If all client tasks send the same 
kind of data to the main task, a single entry that is called by all 
client tasks would be enough (perhaps it needs a parameter that tells 
which client is calling, too).

The "protected object" method is like a "monitor" or a "mailbox": You 
define an object that has some public operations and some private data. 
The "protected" property means that the public operations are associated 
with a mutex that enforces mutual exclusion between the calling tasks 
(well, to be precise, the synchronization allows multiple concurrent 
readers, or one exclusive writer). Some public operations can be 
labelled "entries" which means that there is a Boolean "guard" 
expression, similar to a "condition variable": if a task calls an entry 
subprogram, and the guard is false, the task is suspended until the 
guard becomes true (thanks to some other task calling some other 
operation of the same protected object).

In your case, you could define a protected object that has internal 
buffers to hold data ("events") from the three socket tasks. The socket 
tasks would call operations of this object to store data in the buffers; 
the main task would call an operation to extract data from the buffers; 
the latter operation could be defined as an entry, with a guard that 
makes the main task wait until there is some data in the buffers.

> Unfortunately there's not so much documentation about ADA  =(

Sure there is... for example, the Wikibook at 
http://en.wikibooks.org/wiki/Ada_Programming. You should look at the 
chapter on tasking, at http://en.wikibooks.org/wiki/Ada_Programming/Tasking.

HTH!

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .