Re: Interrupts handling in ADA

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

On 13 Dic, 14:04, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 13 Dec 2011 05:11:14 -0800 (PST), Ada BRL wrote:
> > 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...
>
> You can link to an import library from Ada without any problems. Which OS
> are you using?

Windows 7 64 bit, Home Premium SP1 ...
I have tried in many ways to import symbols but it was impossible...
I had a linker error: couldn't find exported symbols...

I've copied the dll into all the possible folder of my project.
I've even undecorated the exported symbols of my dll created by Visual
Studio 2010 but it hasn't solved the issue.
I've downloaded a dummy dll written without Visual Studio, with
exported dummy function and variable but it hasn't worked.
I've inspected the names of the exported symbols and inside the pragma
import I've used correct ones (I've tried either __my_func_name,
_my_func_name and my_fun_name)...

>
> > I have a maximum of 5 sockets so I guess there will be no problems
> > onto the OS side...I hope so =).
>
> Yep.
>
> > What's the "select" you have just mentioned?
>
> E.g. under Windows:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=...
>
> > The software interrupts are implemented with entry / accept paradigm
> > (like events in C++? ).
>
> No, OS event objects and entry calls assume that the recipient is inactive
> and thus is ready to accept the notification. That is a non-preemptive
> model.

Does this means that the main task has to be in wait for event state
(blocked and so NOT running)?

>
> Software interrupts are preemptive. An interrupt breaks the execution of
> the recipient. Like with exceptions there are two models of what happens
> after interrupt has been serviced: continuation back from the point where
> the task was interrupted vs. winding up the stack and aborting some stuff
> with continuation from a definite point. AST's are usually like former,
> Ada's ATC are like latter.

Sorry what does ATC stand for?

continuation back from the point where
> the task was interrupted vs. winding up the stack and aborting some stuff
> with continuation from a definite point. AST's are usually like former,
> Ada's ATC are like latter.

I haven't understood well...

With entry / accept will I use AST or ATC?

if I have this piece of code inside main task body:

do stuff before;
accept event;
do stuff after;

The main thread is blocked onto "event" barrier, when socket calls
Main.event it can continue and perform "do stuff after".

Code of socket body:

do stuff before;
Main.event;
do stuff after;

Does the socket continue its execution after calling to Main.event, in
parallel with main task or will it be blocked until the main task
blocks itself again onto a barrier?

>
> >> 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?
>
> It is an asymmetric model. The subscriber does not know the publishers. It
> waits for any entry call, services it, and then wait for another.

Perfect!

>
> > Eg: only socket #2 has received some data, can the main task execute
> > or does it have to wait also for the other sockets?
>
> One by one, if you need something like synchronization at the checkpoint,
> that would possible to implement using monitors, but it would be a bit
> hairy. I would use arrays of events instead.

I don't want to wait the reception of messages by every socket (for
example socket 3 may not receive any data at all), I want that
everytime some data is available on a socket (could be 1,2,3 socket(s)
at the same time) the main task receives data and performs some
elaboration on it.

Please tell me if I'm not right: every task append it's event
(data_arrived event) onto the queue.
For this reason the main task enters the running state and pops all
the elements of the queue (events); after having processed all the
events it will enter the blocked state again. Am I right?

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

Is it the same of using Mailbox?


>
> >> 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?
>
> Efficiency depends on the network stack you are using. In general,
> protected objects could be more efficient where context switching is
> expensive. This is because in some cases protected entries can be serviced
> without switching tasks (threads). On the architectures with many cores,
> where switching is relatively cheap and locking is relatively expensive,
> tasks rendezvous might become preferable. However, if you care about
> performance, you have always measure, never guess.
>
> > Simon Wright has posted an example of Protected queue and entry /
> > accept statements and it seems to be simple but effective as well.
>
> See above, speculations about efficiency are dangerous. I would refrain
> copying socket data, but if it works for you, why not?

You said:
I would refrain
> copying socket data,

Roughly speaking, are you suggesting me not to copy the data from
sockets but accessing the same data through "pointers"?
Or, are you suggesting me to avoid context switching?

Thank you!

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