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

[Adam Beneschan <adam@irvine.com>]

On Jan 23, 11:32 am, Ada BRL <ada.brl.2...@gmail.com> wrote:
> Dear all,
>
> I'm experiencing an issue about local and not local pointers...
>
> 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).
> For this reason the server needs to know on which client call the
> entry:
> one time could be the 3th, another the 1st and so on...

I think you should look into protected types, which may be the best
way to solve your problem (or at least some other problems that may be
like yours).

I'm not sure what exactly you're trying to do, but it sounds something
like this: You have a server and a number of clients.  Each client
may, at some point, initiate a certain kind of request to the server.
The client may want to do other things (OK, that might be Tom's idea
and not yours) and then, when it's done, wait for the request to be
completed and retrieve the result data from the server.

I think the problem is that using "accept" to wait for the server to
complete the request doesn't work very well, especially when your
clients are of several different task types.  There's no way in Ada to
get the server to call a Receive entry without knowing the type of the
task declaring the entry; even if the entries of different task types
all have the same name Receive and the same parameter profile, it just
won't work.  J-P mentioned using interfaces but I think this could get
messy.

A better idea (in my opinion) is to set things up so that the client
will *call* an entry, rather than accept an entry, when it's ready to
wait for the request to be completed.  It can't be an entry in the
server, though, since there's no construct in Ada to "accept" an entry
just from one specific task.  In Ada 83, I would have had the server
create a new, small "helper" task for this purpose; the server would
create a new task when the request is initiated, and later it would
tell that task when the request can be completed, and the client would
wait on that task.  Now, protected types can be used for a similar
purpose.  Something like:

  protected type Request_Control is
     entry Retrieve_Data (Data : String);
     -- other entries that the server would use
  end Request_Control;
  type Request_Control_Acc is access all Request_Control;

Then, the client would do something like:

  Req : Request_Control_Acc;

  loop
     Server.Send_Data (Data, Req);  -- where Req is an OUT parameter
                                    -- to the entry
     -- do some other stuff
     -- then when you're ready to retrieve the result:
     Req.Retrieve_Data (Data);
     -- etc.
  end loop;

The server, when it gets Send_Data, would allocate a new
Request_Control and give the access back to the client.  The server
would also save this access in its own tables so that it can
communicate with it when it's ready to signal that the request is
complete.  Later, the server would call some other operation of
Request_Control when the request is complete, and this would open up
the Retrieve_Data entry so that the client can now unblock (if it is
waiting on Retrieve_Entry) and retrieve the data.

This would also work if your client has two tasks and you want one
task to initiate the request and the other to retrieve the data (I'm
not sure if this is what you meant in one of your later posts).  The
first task would just have to get the Req value to the second task
somehow.

I'll let you read about protected types and figure out how you'd set
them up to make everything work.

Again, I don't know if this is exactly the kind of problem you're
trying to solve, but something like this would help with a lot of
problems in the same class, so hopefully it will be of some use.

                                    -- Adam