Re: Interrupts handling in ADA

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

Sorry, I replied you privately before, instead of the group.


On 11 Dic, 12:04, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 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?

I have several tasks:

Ada side:
3 sockets communicating with C/C++ sockets plus main task,

C/C++ side:
lots of threads, 3 of these are sockets communicating with Ada
sockets.

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

As I asked in another post, what's the select statement? :-)

>
> (That'shttp://en.wikibooks.org/wiki/Ada_Programming/Tasking#Rendezvous
> on the page mentioned by Niklas Holsti. There is alsohttp://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

Using Mailbox, is the socket task  - that has received the data and
called the accept event - blocked while the main task runs?

Eg:
Socket1.data_arrived;

Inside main task: accept data_arrived;

Is at this point Socket1 blocked or not?

Another question:

Inside the main task, do I have to specify different entries for all
the sockets like:
E.g.:
entry data_arrived_1; -- for socket #1
entry data_arrived_2; -- for socket #2
entry data_arrived_3; -- for socket #3

and then
accept data_arrived_1;
accept data_arrived_2; etc...

or I have to specify just one entry and I call it from different
socket tasks?
E.g.:
socket1.data_arrived;
socket2.data_arrived; etc...

I guess it's the second option because in the first case for example
the accept data_arrived_2 cannot be executed until data_arrived_1 is
called.

Thanks!