Re: Interrupts handling in ADA

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 10.12.11 21: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... =( ]

Just to make sure: Do you have 4 Ada tasks that should
communicate, or do you have an Ada program and 3 programs
or pthread style functions written in C or C++ that should
communicate with the Ada program?

In the first case, simply look for "entry", "select", and "accept",
These means of inter-task communications have been built into Ada
since day 1.

(That's
http://en.wikibooks.org/wiki/Ada_Programming/Tasking#Rendezvous
on the page mentioned by Niklas Holsti. There is also
http://www.adaic.org/learn/materials/ )

Say I have two task objects A and B, and B should accept calls from other
tasks at an entry named "Data_Available". The notification is written
in the body the calling task, A in this case. It could look like

    ...
    B.Data_Available;  --  A notifies B
    ...

Done. That's all. If A also wishes to send data directly, then
B would accept them simply in a parameter. Then, "Data_Available"
would have been declared with a parameter instead of without one
as in the case above.
The notification, which then includes data to be sent, could look like

    ...
    B.Data_Available (Data_To_Be_Sent);
    ...

It is also possible to combine the first, simple notification (without
data) with employing a third object, a mailbox style object, as outlined
in other answers in this thread.  The mailbox can be a protected object
(language defined term, roughly clever type for shared variables with mutex
and conditional waiting), or another dedicated task object. The model
in either case  is:

    -- body of A:
    Mailbox.Add_Data (Data_for_B);  -- make data available
    B.Data_Available;   -- notify B of data available, as before
    ...

    -- body of B:
    accept Data_Available;  -- be notified of data available in mailbox
    Mailbox.Get_Data (Storage => Room_for_Data);
       -- load from mailbox and store into a variable local to B

Or you could have B wait at the mailbox until A makes data
available in the mailbox. The tasks would not have to communicate
directly, then.  For this to work, the Mailbox object will
a procedure for tasks that wish to add data to the mailbox, and
an entry for tasks that wish to get data out of the mailbox,
"E" say. The entry is guarded by a barrier. The barrier
will get lifted as soon as a task such as a A has supplied data
to the box. The effect is then that a task like B, having waited
in the queue of entry "E", will be "notified" of the presence
of data and continues, i.e., loads data from the mailbox.



- HTH Georg