Re: Pointer to instance of indefinite array?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 13 Aug 2014 09:06:51 -0700 (PDT), NiGHTS wrote:

> Is it possible to have a constrained array of indefinite arrays without
> using access?

Yes, if the semantics is by-value/copy

> In my target program, the "Do_Something_With_Array" function is actually
> an interface to a FIFO queue where groups of indefinite arrays are
> temporarily buffered for use by another task. Of course this will be via
> an entry to a protected object but those details aside how can I construct
> a constrained array of indefinite arrays?

I have several questions to that:

1. Do you really need marshaling? You say you buffer arrays that means the
producer and consumer are decoupled and you could enqueue several request
before servicing one. Is to so? Because in a synchronous schema when
requests are serviced as they appear you don't need to marshal requests.
You simply do a rendezvous from the producer to the consumer and do not
copy anything. This is also possible to implement though a protected object
(but would require an access type). In both cases the producer holds the
array, which is possible due to synchronicity.

2. It is almost always a bad idea to service requests in a protected
operation. Since you are working with arrays, it would involve loops, which
is certainly not good to do within such an operation. Sooner or later you
would like to do some I/O or other blocking stuff.

3. 1-1 FIFO actually does not need locking. You can implement it without
protected objects. One possible implementation is here

http://www.dmitry-kazakov.de/ada/components.htm#Generic_Indefinite_FIFO

It works with indefinite arrays. Arrays will copied in and out (marshaled).

4. For n-1, 1-m, n-m FIFOs, deploying a mutex for interlocking is almost
always better than servicing on the context of a protected action. It might
be slightly slower but much safer. A FIFO end with has 1 task attached can
access FIFO in a lock-free manner. E.g. for n-1, you must interlock only
producers etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de