Re: "C - like: THIS" pointer to a task type inside a task function

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

I have already inserted a post but it isn't visualized yet...

On 23 Gen, 19:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 23 Jan 2012 11:32:39 -0800 (PST), Ada BRL wrote:
> > I've N clients and one server that communicate each other.
> > The N clients retrieve data dynamically, send it to the server throgh
> > enrty call (obviously the server can accept just one call per time)
> > and wait for the reply from the server (through accept statement).
>
> A server cannot wait for itself either "through accept statement" or any
> other way.
>
>    T4.Send_Data (Data);
>    accept Retrieve_Data (Data);
>

I made a mistake, sorry ... :-(

I have two tasks for every channel of communication:
- input task: retrieves data from the net and send it to the server
(call it Ti_IN),
- output task: receives data from the server and send it on the net
(call it Ti_OUT).

For this reason I need:
1) to know who's sending data to the server --> I've already
implemented it with "in" parameter,
2) have a reference to the output threads, in order to call every time
the entry of the correct thread.

For example:
T2_IN calls Server.Send_Data(Data, 2);
Inside the server I have to call T2_OUT.Retrieve_Data(Data);
and NOT the entry on T1_OUT or T3_OUT.

So the entry Retrieve_Data is implemented only by the _OUT tasks.


> is a patented way to run into a deadlock.

I recognize you are definitely true :-)!

>
> > For this reason the server needs to know on which client call the
> > entry:
>
> That does not follow. Why do the server need to know the caller?
>
> > package P1 is
>
> >    task type T1 is
> >            entry Retrieve_Data(Data : String);
>
>    entry Exchange_Data (Data : in out String);
>
> An entry can have in, out, in-out parameters like a subprogram call. You
> can pass parameters in and get the results out, just in one call.
>
> > I think this is a quite common problem and so I'm optimistic to
> > receive some useful replies!
>
> It is considered bad design when two components know each other. Usually
> the software is designed in a way that component relationships are
> asymmetric, e.g. the callee knows nothing about the caller. Component knows
> nothing about the container, etc. The advantage of this approach is its
> robustness. You can have as many callers you need without changing the
> callee. Imagine, that sine from the math library would have to be modified
> each time somebody writes a program calling it. For concurrency symmetric
> relationships impose an additional risk of deadlocking.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Thank you very much and sorry for the mistake....but yesterday I have
been programming for lots of hours without any rest...