Does GNAT support a thread-free RTS?
Simon Wright
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?
J-P. Rosen
> 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.
>
--
---------------------------------------------------------
J-P. Rosen (ro...@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
John B. Matthews
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>
an...@att.net
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.
Pascal Obry
> 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.
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
Simon Wright
> 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
From the Changelog for FSF GCC:
2005-02-09
* gnat_ugn.texi: Remove all mentions of FSU threads, which are no
longer supported.
an...@att.net
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.
Simon Wright
> 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".
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.
would be a major task to backport it.
>>Le 11/09/2011 11:49, an...@att.net a écrit :
Top post, please!
Ludovic Brenta
>> 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
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.
Ludovic Brenta
> 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.
Ludovic Brenta
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.
Robert A Duff
> - 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.
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
Rugxulo
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."
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.)
an...@att.net
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.
Ludovic Brenta
> EZ2LOAD (old GNAT on Simtel.net circa 1998) using DJGPP (DOS).
CVSUP for use by FreeBSD?
--
Ludovic Brenta.
Ludovic Brenta
>> 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?
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.
Simon Wright
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.
Georg Bauhaus
> 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).
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.
Peter C. Chapin
> Simon Wright<si...@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).
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.
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
Dmitry A. Kazakov
> 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
Robert A Duff
> Protected objects are not tagged, ...
Protected types are tagged if they are derived from synchronized interfaces.
- Bob
Dmitry A. Kazakov
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.
Georg Bauhaus
> 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.
Dmitry A. Kazakov
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.
Georg Bauhaus
"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;
Dmitry A. Kazakov
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.