Does GNAT support a thread-free RTS?

Does GNAT support a thread-free RTS?

[Simon Wright]

It used to be that you could configure GNAT to use a tasking RTS that
didn't use threads; tasks were scheduled entirely within the RTS. I
think these may be called 'green threads'[1]. Of course, this meant that
blocking on I/O would block the whole program, but for some purposes it
might be ideal.

I don't see any trace of this in FSF GCC; has it gone for good?

[1] http://en.wikipedia.org/wiki/Green_threads

Re: Does GNAT support a thread-free RTS?

[J-P. Rosen]

Le 10/09/2011 17:19, Simon Wright a �crit :
> It used to be that you could configure GNAT to use a tasking RTS that
> didn't use threads; tasks were scheduled entirely within the RTS. I
> think these may be called 'green threads'[1]. Of course, this meant that
> blocking on I/O would block the whole program, but for some purposes it
> might be ideal.
> 
No, it used the FSU threads

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Does GNAT support a thread-free RTS?

[John B. Matthews]

In article <j4hqvt$6pa$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> 
wrote:

> Le 10/09/2011 17:19, Simon Wright a écrit :
> > It used to be that you could configure GNAT to use a tasking RTS that
> > didn't use threads; tasks were scheduled entirely within the RTS. I
> > think these may be called 'green threads'[1]. Of course, this meant that
> > blocking on I/O would block the whole program, but for some purposes it
> > might be ideal.
> > 
> No, it used the FSU threads

FSU threads were used to implement Ada tasking in Tenon's MachTen and 
CodeBuilder products for Mac OS 9.

<http://www.tenon.com/products/machten/>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Does GNAT support a thread-free RTS?

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

Unless 2011 has change the default run-time library, 
When GNAT is installed the RTL is rts-native. Native uses the 
thread package of the underlying OS.

"FSU threads library", "pthreads library" (Solaris only), 
"Zero-Cost Exceptions" ("ZCX"), and "setjmp/longjmp" 
("SJLJ"), are optional if compiled, by using the "--RTS=" 
command line option.

Note: "FSU threads library" provide a completely accurate implementation 
of Annex D. Since "Glade" was replaced, not sure if GNAT, still provide 
a true implementation of Annex D.



In <nospam-6370B2.05223211092011@news.aioe.org>, "John B. Matthews" <nospam@nospam.invalid> writes:
>In article <j4hqvt$6pa$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> 
>wrote:
>
>> Le 10/09/2011 17:19, Simon Wright a écrit :
>> > It used to be that you could configure GNAT to use a tasking RTS that
>> > didn't use threads; tasks were scheduled entirely within the RTS. I
>> > think these may be called 'green threads'[1]. Of course, this meant that
>> > blocking on I/O would block the whole program, but for some purposes it
>> > might be ideal.
>> > 
>> No, it used the FSU threads
>
>FSU threads were used to implement Ada tasking in Tenon's MachTen and 
>CodeBuilder products for Mac OS 9.
>
><http://www.tenon.com/products/machten/>
>
>-- 
>John B. Matthews
>trashgod at gmail dot com
><http://sites.google.com/site/drjohnbmatthews>

Re: Does GNAT support a thread-free RTS?

[Pascal Obry]

Le 11/09/2011 11:49, anon@att.net a écrit :
> Note: "FSU threads library" provide a completely accurate implementation
> of Annex D. Since "Glade" was replaced, not sure if GNAT, still provide
> a true implementation of Annex D.

And since GLADE has nothing to do with threading (FSU or native) and 
Annex D the above comment seems highly misleading.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Does GNAT support a thread-free RTS?

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

Reference: GCC.GNU.org and Adacore.com

My point is. Since "Glade" was put out to pasture, there is no package 
that fulfil the requirement for Annex D, that is stated for the "FSU threads" 
RTL. Because, "PolyOrb" does not meet the "completely accurate 
implementation of Annex D." requirement for "FSU threads".

Plus, between 2004 .. 2010 for Linux (binary package) from 
Libre.Adacore.com only contains native, siji, and maRTE libraries 
only. No default FSU or ZCX RTL. If still available you will have 
to download source and compile your own version to get FSU threads.

In <4E6C8D7D.2020803@obry.net>, Pascal Obry <pascal@obry.net> writes:
>Le 11/09/2011 11:49, anon@att.net a écrit :
>> Note: "FSU threads library" provide a completely accurate implementation
>> of Annex D. Since "Glade" was replaced, not sure if GNAT, still provide
>> a true implementation of Annex D.
>
>And since GLADE has nothing to do with threading (FSU or native) and 
>Annex D the above comment seems highly misleading.
>
>Pascal.
>
>-- 
>
>--|------------------------------------------------------
>--| Pascal Obry                           Team-Ada Member
>--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
>--|------------------------------------------------------
>--|    http://www.obry.net  -  http://v2p.fr.eu.org
>--| "The best way to travel is by means of imagination"
>--|
>--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>

Re: Does GNAT support a thread-free RTS?

[Simon Wright]

anon@att.net writes:

> Reference: GCC.GNU.org and Adacore.com
>
> My point is. Since "Glade" was put out to pasture, there is no package
> that fulfil the requirement for Annex D, that is stated for the "FSU
> threads" RTL. Because, "PolyOrb" does not meet the "completely
> accurate implementation of Annex D." requirement for "FSU threads".

Why would you expect PolyORB (NB, capitalisation) to meet any Annex D
requirements?

PolyORB is an implementation for Annex E, Distributed Systems, not D,
Real-Time Systems.

And, in any case, most often the motivation for using tasks is to
support I/O, and that is something that FSU threads were precisely the
wrong solution for.

> Plus, between 2004 .. 2010 for Linux (binary package) from 
> Libre.Adacore.com only contains native, siji, and maRTE libraries 
> only. No default FSU or ZCX RTL. If still available you will have 
> to download source and compile your own version to get FSU threads.

See my note above; FSU support was withdrawn from GNAT in 2005, so it
would be a major task to backport it.

> In <4E6C8D7D.2020803@obry.net>, Pascal Obry <pascal@obry.net> writes:
>>Le 11/09/2011 11:49, anon@att.net a écrit :

Top post, please!

Re: Does GNAT support a thread-free RTS?

[Ludovic Brenta]

anon wrote on comp.lang.ada:
> Reference: GCC.GNU.org and Adacore.com
>
> My point is. Since "Glade" was put out to pasture, there is no package
> that fulfil the requirement for Annex D, that is stated for the "FSU
> threads" RTL. Because, "PolyOrb" does not meet the "completely accurate
> implementation of Annex D." requirement for "FSU threads".
>
> Plus, between 2004 .. 2010 for Linux (binary package) from
> Libre.Adacore.com only contains native, siji, and maRTE libraries
> only. No default FSU or ZCX RTL. If still available you will have
> to download source and compile your own version to get FSU threads.

Presumably, by "siji" you meant "sjlj" which stands for "setjump/
longjump exception handling".  GCC presently comes with two run-time
systems:

- zero-cost exception handling aka ZCX aka "native", which is the
default
  on most architectures.  The phrase "zero-cost" really means "zero
  distributed cost" which means you do not pay a performance penalty
unless
  and until you raise an exception.  Raising an exception is however
costly.

- sjlj aka setjump/longjump, which is the alternative, in which every
frame
  that might possibly raise an exception calls setjmp(3), thus
incurring
  distributed cost, and raising an exception calls longjmp(3), which
is
  cheap compared to the raising of an exception with ZCX.  sjlj is the
only
  supported run-time system on a few, non-mainstream architectures.

Both run-time systems now use native threads and both support Annex D
(real-time systems) insofar as the underlying kernel does.  The old
FSU threads were intended to provide better support for Annex D but
that was rendered unnecessary by the advances in Linux, Solaris and
other kernels.

It is true that, a few years ago, Glade used to require the sjlj run-
time system to implement exception handling across partitions in in
distributed programs (Annex E).  I know because I packaged it for
Debian.  However, PolyORB has not required sjlj since it introduced
support for Annex E in version 2.2.

--
Ludovic Brenta.
The stakeholders enable the educated core business by leveraging the
plannings.

Re: Does GNAT support a thread-free RTS?

[Ludovic Brenta]

I forgot to add that, as Pascal said, ZCX and SJLJ have nothing to do
with tasking, so bringing that up in a discussion about FSU vs. native
threads as though it had an influence is indeed misleading.  My
previous post was to clarify the present state of GNAT and the
underlying concepts.

--
Ludovic Brenta.
The group embraces non-linear lessons learned.

Re: Does GNAT support a thread-free RTS?

[anon]

Packages that are used in Annex E: "Distributed Systems" must take 
assurances that some system I/O operations will not cause a deadlock or 
other blocks to some or all task within the Ada partition. Which means 
that any package that fully supports Annex E: "Distributed Systems" must 
also fully support Annex D: "Real-Time System".

But as a number of posted stated ( since 2008, when Adacore drop "Glade" 
for "Polyorb" ) that Annex E is no longer fully supported in GNAT.  Which 
means that GNAT using "Polyorb" will not meet the criteria in Annex E. So, 
it is possible that in Concurrent Ada, "Polyorb" may allow some to all 
task to become blocked or an Ada partition to be completily deadlock 
aka violating criteria in Annex D. 


In <bac766cf-8dd0-4b41-a912-a0248df9f8b7@h7g2000yqm.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>I forgot to add that, as Pascal said, ZCX and SJLJ have nothing to do
>with tasking, so bringing that up in a discussion about FSU vs. native
>threads as though it had an influence is indeed misleading.  My
>previous post was to clarify the present state of GNAT and the
>underlying concepts.
>
>--
>Ludovic Brenta.
>The group embraces non-linear lessons learned.

Re: Does GNAT support a thread-free RTS?

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> - sjlj aka setjump/longjump, which is the alternative, in which every
> frame
>   that might possibly raise an exception calls setjmp(3), thus
                        ^^^^^

You meant "handle".

> incurring
>   distributed cost, and raising an exception calls longjmp(3), which
> is
>   cheap compared to the raising of an exception with ZCX.  sjlj is the
> only
>   supported run-time system on a few, non-mainstream architectures.

Right.  ZCX is the "right" way to implement exception handling,
because raising exceptions is rare, whereas exception handlers
(and finalizable objects) are not-so-rare, so you want to pay the
cost on the raise.

- Bob

Re: Does GNAT support a thread-free RTS?

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 10/09/2011 17:19, Simon Wright a écrit :
>> It used to be that you could configure GNAT to use a tasking RTS that
>> didn't use threads; tasks were scheduled entirely within the RTS. I
>> think these may be called 'green threads'[1]. Of course, this meant that
>> blocking on I/O would block the whole program, but for some purposes it
>> might be ideal.

> No, it used the FSU threads

Thanks, all, for that.

From the Changelog for FSF GCC:

2005-02-09  
	* gnat_ugn.texi: Remove all mentions of FSU threads, which are no
	longer supported.

Re: Does GNAT support a thread-free RTS?

[Ludovic Brenta]

J-P. Rosen wrote on comp.lang.ada:
> Simon Wright a écrit :
>> It used to be that you could configure GNAT to use a tasking RTS that
>> didn't use threads; tasks were scheduled entirely within the RTS. I
>> think these may be called 'green threads'[1]. Of course, this meant that
>> blocking on I/O would block the whole program, but for some purposes it
>> might be ideal.
>
> No, it used the FSU threads

The FSU threads library was a kind of green threads.  The GNAT User's
Guide of GCC 3.4 used to say: "The FSU threads package operates with
all Ada tasks
appearing to the system to be a single thread."

--
Ludovic Brenta.
The human resources streamline the executive talents, while the
Quality Research results in a SWOT analysis from the get-go.

Re: Does GNAT support a thread-free RTS?

[Rugxulo]

Hi,

On Sep 12, 2:19 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> J-P. Rosen wrote on comp.lang.ada:
>
> > Simon Wright a écrit :
> >> It used to be that you could configure GNAT to use a tasking RTS that
> >> didn't use threads; tasks were scheduled entirely within the RTS. I
> >> think these may be called 'green threads'[1]. Of course, this meant that
> >> blocking on I/O would block the whole program, but for some purposes it
> >> might be ideal.
>
> > No, it used the FSU threads
>
> The FSU threads library was a kind of green threads.  The GNAT User's
> Guide of GCC 3.4 used to say: "The FSU threads package operates with
> all Ada tasks
> appearing to the system to be a single thread."

At the risk of showing my goofy bias and being offensively "obsolete"
or luddite here, let me mention:  FSU pthreads used to be included in
EZ2LOAD (old GNAT on Simtel.net circa 1998) using DJGPP (DOS).
However, AFAICT (only very limited testing, esp. since I don't grok
Ada yet), modern GNAT 4.6.1 [2011] for DJGPP doesn't support tasking,
not even with FSU pthreads (not included). This may be because it
(lib) wasn't maintained since year 2000 (and supposedly vaguely
conflicted with DJGPP libc newer than 2.00 [circa 1996]).

Recently some minor patching was done by one guy to compile p7zip 9.13
with DJGPP (again), this time using (fixed) FSU pthreads instead of
(vaguely buggy, slower, more complex, abandoned) GNU pth + Watt-32
(socket lib, required by GNU pth).

Yes, green threads are good if you want to support a lot of non-
mainstream OSes. But even projects like Ruby 1.9.x have abandoned such
ideas. This is why Ruby no longer supports as many platforms as in the
1.8.7 days (e.g. DOS and others). (What about Java 1.1? Wasn't that
green threads? There was an old commercial DOS port of JavaPC in 1997
via DJGPP. Yes, confirmed at Wikipedia.)

<off-topic rant>
It's not just tasking / threading, of course, it's also that such
systems are rarer or harder to maintain or just less popular. Also the
lack of nowadays "crucial" things such as Unicode support or newer GNU
tools probably doesn't help either. I'm not really complaining, just
sad that "portable" things have to be so expensive that only a very
few (usually the big three) mainstream OSes can support anything these
days.
</off-topic rant>

I guess? I should mention that typically popular, vanilla "DOS" (MS-
DOS and clones, e.g. FreeDOS) doesn't support threads at all. There
are several DOS-compatible systems (PC-MOS? TSX-32? Real/32? DR-DOS 7?
RDOS?) that do support 'em, but most people (myself included) haven't
extensively (or even never) used them. Just in case someone whines
that it doesn't exist, heh.  ;-)

P.S. I expect no sympathy for DOS, and thus I almost hate to even
bring it up here! But hey, perhaps it sheds some light. (Corrections
or additions welcome.)

Re: Does GNAT support a thread-free RTS?

[Ludovic Brenta]

Rugxulo writes:
> EZ2LOAD (old GNAT on Simtel.net circa 1998) using DJGPP (DOS).

I thought EZ2LOAD was a partial Modula-3 compiler intended to compile
CVSUP for use by FreeBSD?

-- 
Ludovic Brenta.

Re: Does GNAT support a thread-free RTS?

[Ludovic Brenta]

Ludovic Brenta wrote on comp.lang.ada:
> Rugxulo writes:
>> EZ2LOAD (old GNAT on Simtel.net circa 1998) using DJGPP (DOS).
>
> I thought EZ2LOAD was a partial Modula-3 compiler intended to compile
> CVSUP for use by FreeBSD?

Replying to myself: the partial Modla-3 compiler was called Ezm3,
EZ2LOAD was indeed an Ada compiler.

--
Ludovic Brenta.
Our SWOT analysis targets the powerful champion; nevertheless our
awesome and efficient governances interact with holistic systems.

Re: Does GNAT support a thread-free RTS?

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> It used to be that you could configure GNAT to use a tasking RTS that
> didn't use threads; tasks were scheduled entirely within the RTS. I
> think these may be called 'green threads'[1]. Of course, this meant that
> blocking on I/O would block the whole program, but for some purposes it
> might be ideal.
>
> I don't see any trace of this in FSF GCC; has it gone for good?
>
> [1] http://en.wikipedia.org/wiki/Green_threads

My prompt for asking this was a colleague who was used to Erlang and was
complaining that GNAT's use of OS threads meant he would have to change
his design mindset to not use thousands of tasks (Erlang processes).

I believe Scala is similar.

I believe that Erlang allows you to classify some threads as
maybe-io-bound.

Re: Does GNAT support a thread-free RTS?

[Georg Bauhaus]

On 13.09.11 10:30, Simon Wright wrote:

> My prompt for asking this was a colleague who was used to Erlang and was
> complaining that GNAT's use of OS threads meant he would have to change
> his design mindset to not use thousands of tasks (Erlang processes).

Just an idea: using mostly functions together with protected
channel objects should allow to use Ada in a way one
might be used to when passing Erlang data around.
 You write to some entry/procedure of a PO (pass data down
the channel) and read from some entry/function of the PO
(read from a channel). Add barriers as needed.

Re: Does GNAT support a thread-free RTS?

[Dmitry A. Kazakov]

On Tue, 13 Sep 2011 11:39:16 +0200, Georg Bauhaus wrote:

> On 13.09.11 10:30, Simon Wright wrote:
> 
>> My prompt for asking this was a colleague who was used to Erlang and was
>> complaining that GNAT's use of OS threads meant he would have to change
>> his design mindset to not use thousands of tasks (Erlang processes).
> 
> Just an idea: using mostly functions together with protected
> channel objects should allow to use Ada in a way one
> might be used to when passing Erlang data around.

Unfortunately this does not work this way for many reasons (I have
evaluated this design for our middleware and quickly dropped the idea). 

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.

>  You write to some entry/procedure of a PO (pass data down
> the channel) and read from some entry/function of the PO
> (read from a channel). Add barriers as needed.

Of course this can only be the transport layer. In our design at the
application layer the channels are multiplexed into typed named channels,
so that you can exchange data as if you had one channel per each variable
and in full duplex mode of course.

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

Re: Does GNAT support a thread-free RTS?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Protected objects are not tagged, ...

Protected types are tagged if they are derived from synchronized interfaces.

- Bob

Re: Does GNAT support a thread-free RTS?

[Dmitry A. Kazakov]

On Tue, 13 Sep 2011 10:02:12 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Protected objects are not tagged, ...
> 
> Protected types are tagged if they are derived from synchronized interfaces.

Effectively not, for design purpose they should be usable as parent types
to derive from, protected operations has to be primitive.

An inability to push implementations down the hierarchy (which is also the
case for Ada's MI) poses a huge problem for the designer and for the end
users.

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

Re: Does GNAT support a thread-free RTS?

[Georg Bauhaus]

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"?

Re: Does GNAT support a thread-free RTS?

[Dmitry A. Kazakov]

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.

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

Re: Does GNAT support a thread-free RTS?

[Georg Bauhaus]

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.

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, 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?

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

    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;

private
    type Poly_Cell is access constant Any'Class;
    type Box is tagged
        record
           Storage :  Poly_Cell;
        end record;
end Sys;


package Sys.Messages is

    type Vector is array (Natural range <>) of Box;
    --  a channel object's container of boxes; message box

    protected type Channel (Capacity : Natural) is

       entry Send (Object : in Box);
       --  ! operation

       entry Receive (Object : out Box);
       --  pattern matching will correspond to dispatching
       --  based on what is in `Object`

    private
       Queue : Vector (1 .. Capacity);
       Front : Natural := 0;
       Rear : Natural := 0;
    end Channel;

end Sys.Messages;


with Sys.Messages;

procedure Test_Sys is

    use Sys;

    --  a user-defined type that has the same interface as `Sys.Any`:

    type Taste is (Sour, Sweet, EU);

    type Apple is new Sys.Any with
        record
           Quality : Taste;
        end record;

    Foul: exception;

    C1 : Messages.Channel (Capacity => 5);

    Granny_Smith : Apple := (Any with Quality => Sour);

    Gift : Box := Ref (Granny_Smith);

begin
    C1.Send (Gift);
    C1.Send (Gift);
    Granny_Smith.Quality := EU;  -- tamper with trees
    C1.Receive (Gift);
    C1.Receive (Gift);
    if Apple(Deref(Gift).all).Quality /= Sour then
       raise Foul;
    end if;
end Test_Sys;


package body Sys is

    function Ref (Item : Any'Class) return Box is
    begin
       return Box'(Storage => Item'Unchecked_Access);
    end Ref;

    function Deref (This : Box) return access constant Any'Class is
    begin
       return This.Storage;
    end Deref;

end Sys;


package body Sys.Messages is

    protected body Channel is
       entry Send (Object : Box) when Rear < Capacity is
       begin
          Rear := Rear + 1;
          Queue (Rear) := Object;
       end Send;

       entry Receive (Object : out Box) when Front < Rear is
       begin
          Front := Front + 1;
          Object := Queue (Front);
          if Front = Rear then
             Front := 0; Rear := 0;
          end if;
       end Receive;
    end Channel;

    function Ref (Item : Any'Class) return Box is
    begin
       return Box'(Storage => Item'Unchecked_Access);
    end Ref;

    function Deref (This : Box) return access constant Any'Class is
    begin
       return This.Storage;
    end Deref;

end Sys.Messages;

Re: Does GNAT support a thread-free RTS?

[Dmitry A. Kazakov]

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

Re: Does GNAT support a thread-free RTS?

[Peter C. Chapin]

On 2011-09-13 04:30, Simon Wright wrote:

> Simon Wright<simon@pushface.org>  writes:
>
> My prompt for asking this was a colleague who was used to Erlang and was
> complaining that GNAT's use of OS threads meant he would have to change
> his design mindset to not use thousands of tasks (Erlang processes).

If one is in control of the run time library and if the underlying OS 
supports asynchronous I/O, then I believe it is possible to write a user 
mode thread library that works "nicely" even in the face of I/O 
operations. When calling an I/O operation that might block the library 
uses asynchronous I/O so that the single kernel thread can be scheduled 
onto a different user thread while the I/O completes.

> I believe Scala is similar.

In Scala you can create "thread based" actors that consume a single 
thread each or "event based" actors that can all share a single thread. 
I haven't experimented with this but my guess is that if you do a 
blocking operation while handling an event you may well tie up all event 
based actors. I imagine the thread based actors would continue to work, 
however.

Peter