Re: Does GNAT support a thread-free RTS?

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

On Tue, 13 Sep 2011 23:22:52 +0200, Georg Bauhaus wrote:

> On 13.09.11 22:35, Dmitry A. Kazakov wrote:
>> On Tue, 13 Sep 2011 18:54:53 +0200, Georg Bauhaus wrote:
>>
>>> On 13.09.11 14:18, Dmitry A. Kazakov wrote:
>>>
>>>> Protected objects are not tagged, you need inheritance to provide typed
>>>> channels. You meed multiple dispatch to handle channel-type + value-type
>>>> hierarchies. You need entries returning indefinite values. You need MI to
>>>> have handles to the channels/devices implementing the interface of a
>>>> protected object.
>>>
>>> Is there an AI on "limited holders"?
>>
>> Holder is useless without delegation, interface inheritance, MI, otherwise
>> it quickly becomes an endless swamp of generic instantiations. Note also
>> classical MD case: channel-type x value-type (<=>  handle-type).
>>
>> BTW, protected objects are unsuitable for distributed interfaces anyway.
>> You need a background task to prevent blocking upon I/O. The usual
>> technique of re-queueing does not help here. The interfaces must be tasks,
>> rather than objects.
> 
> To be fair, writing Erlang is perhaps associated with a more
> "pragmatic" attitude towards static typing, which means you
> will be tracing and debugging anyway when looking for things
> frequently detected by Ada compilers before running the program.
> 
> With this in mind, an owner of a protected channel object (Ada)
> can "receive" (access to) Any'Class objects and trigger dispatching
> calls, primitive subprograms of the received objects, where Erlang
> would perform a case distinction.

However implemented, this call can only initiate I/O.

> Can "agents" then simply share a physical task by being selected
> for acting, perhaps triggered by messages sent (rendezvous if ready),
> or by some simple scheduler task selecting them in a round robin fashion,
> or in a way that resembles reacting to HTTP requests in AWS?

Yes, they do. In my design, there is a queue to the I/O task (of a
"device"), to which the operation is queued. Note how this resembles the
behavior of a entry task, being unable to become one.

> Yes, when some agent needs to both deliver a message and be
> sure the message is sent, then it may wait in the channel's queue
> forever until delivery is signaled.  If the system allows messages
> to be dropped, then barriers can reflect this permission.
> How would tasks be more helpful?

Yes there is much stuff coming with. You want to be able to wait for a
completion. You want to be able to cancel the operation pending. You want
all temporary objects freed. You want references between objects and their
marshaled parts etc.

To much disappointment, though this appears very similar to how Ada tasks
works, it is impossible to promote as a task or reuse task mechanics
(queues for example).

> Thus, reducing the Channel PO to a very basic thing,
> and, unfortunately, exhibiting all the pointers inherent
> in most functional programming languages,
> 
> package Sys is
> 
>     type Any is abstract tagged limited null record;
>     --  ... parent/interface of every message type

Nope, you want to send/receive types, e.g. Integer, not messages. For
"messages" there is already Stream_Array, uninteresting.

>     type Box is tagged private;
>     --  holds a value of type `Any'Class`; see `Ref` and `Deref`
> 
>     --  functions for wrapping and unwrapping:
>     function Ref (Item : Any'Class) return Box;
>     function Deref (This : Box) return access constant Any'Class;

You don't need that, it has values semantics, because things are marshaled.
I have reference-counted handles to the devices and variables
("registers"), but that is mostly because of the language. From the
application point of view, the scopes of devices and variables are static.
Counters are used because there is no way to express their dependencies in
a static manner.

>     protected type Channel (Capacity : Natural) is
> 
>        entry Send (Object : in Box);
>        --  ! operation

That is a "device" interface (the transport layer [*]). Actually Send is a
primitive operation of a register, rather than the device (the application
layer). When you do Send, you queue to the device an I/O request with a
reference to the register. You also return back the request object to the
caller, in order to be able to wait for it or cancel it. You may have
several requests pending on a variable, if the underlying protocol support
this.

This is how it looks like in my design:

   Device : EtherCAT_Device_Handle := Create (Name, Adapter);
   Output : Middleware.Output.Integers_16.Register_Handle := ... 
   ...
   Output.Send (123);  -- Asynchronous send
   Output.Wait;  -- Wait for completion
   Output.Write (456);  -- Synchronous send and wait

And do not forget the opposite direction:

   Input.Request;  -- Asynchronous request
   X := Input.Wait;  -- Wait for completion
   Y := Input.Read;  -- Synchronous request and wait

----
* It cannot be a protected object either, because you want reusable
implementations of the devices. E.g. I have abstract half-duplex device
driver with abstract primitive operations. Protected objects are not
composable upon inheritance. The object you had in mind is still there, but
in the form of a specialized lock object hidden deep inside.

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