* Does GNAT support a thread-free RTS? @ 2011-09-10 15:19 Simon Wright 2011-09-11 8:20 ` J-P. Rosen 2011-09-13 8:30 ` Simon Wright 0 siblings, 2 replies; 26+ messages in thread From: Simon Wright @ 2011-09-10 15:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-10 15:19 Does GNAT support a thread-free RTS? Simon Wright @ 2011-09-11 8:20 ` J-P. Rosen 2011-09-11 9:22 ` John B. Matthews ` (2 more replies) 2011-09-13 8:30 ` Simon Wright 1 sibling, 3 replies; 26+ messages in thread From: J-P. Rosen @ 2011-09-11 8:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-11 8:20 ` J-P. Rosen @ 2011-09-11 9:22 ` John B. Matthews 2011-09-11 9:49 ` anon 2011-09-11 10:36 ` Simon Wright 2011-09-12 7:19 ` Ludovic Brenta 2 siblings, 1 reply; 26+ messages in thread From: John B. Matthews @ 2011-09-11 9:22 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-11 9:22 ` John B. Matthews @ 2011-09-11 9:49 ` anon 2011-09-11 10:29 ` Pascal Obry 0 siblings, 1 reply; 26+ messages in thread From: anon @ 2011-09-11 9:49 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-11 9:49 ` anon @ 2011-09-11 10:29 ` Pascal Obry 2011-09-12 0:33 ` anon 0 siblings, 1 reply; 26+ messages in thread From: Pascal Obry @ 2011-09-11 10:29 UTC (permalink / raw) To: anon; +Cc: anon 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-11 10:29 ` Pascal Obry @ 2011-09-12 0:33 ` anon 2011-09-12 7:27 ` Simon Wright 2011-09-12 9:26 ` Ludovic Brenta 0 siblings, 2 replies; 26+ messages in thread From: anon @ 2011-09-12 0:33 UTC (permalink / raw) [-- 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 0:33 ` anon @ 2011-09-12 7:27 ` Simon Wright 2011-09-12 9:26 ` Ludovic Brenta 1 sibling, 0 replies; 26+ messages in thread From: Simon Wright @ 2011-09-12 7:27 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 0:33 ` anon 2011-09-12 7:27 ` Simon Wright @ 2011-09-12 9:26 ` Ludovic Brenta 2011-09-12 9:49 ` Ludovic Brenta 2011-09-12 13:01 ` Robert A Duff 1 sibling, 2 replies; 26+ messages in thread From: Ludovic Brenta @ 2011-09-12 9:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 9:26 ` Ludovic Brenta @ 2011-09-12 9:49 ` Ludovic Brenta 2011-09-13 1:22 ` anon 2011-09-12 13:01 ` Robert A Duff 1 sibling, 1 reply; 26+ messages in thread From: Ludovic Brenta @ 2011-09-12 9:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 9:49 ` Ludovic Brenta @ 2011-09-13 1:22 ` anon 0 siblings, 0 replies; 26+ messages in thread From: anon @ 2011-09-13 1:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 9:26 ` Ludovic Brenta 2011-09-12 9:49 ` Ludovic Brenta @ 2011-09-12 13:01 ` Robert A Duff 1 sibling, 0 replies; 26+ messages in thread From: Robert A Duff @ 2011-09-12 13:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-11 8:20 ` J-P. Rosen 2011-09-11 9:22 ` John B. Matthews @ 2011-09-11 10:36 ` Simon Wright 2011-09-12 7:19 ` Ludovic Brenta 2 siblings, 0 replies; 26+ messages in thread From: Simon Wright @ 2011-09-11 10:36 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-11 8:20 ` J-P. Rosen 2011-09-11 9:22 ` John B. Matthews 2011-09-11 10:36 ` Simon Wright @ 2011-09-12 7:19 ` Ludovic Brenta 2011-09-12 23:22 ` Rugxulo 2 siblings, 1 reply; 26+ messages in thread From: Ludovic Brenta @ 2011-09-12 7:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 7:19 ` Ludovic Brenta @ 2011-09-12 23:22 ` Rugxulo 2011-09-13 7:03 ` Ludovic Brenta 0 siblings, 1 reply; 26+ messages in thread From: Rugxulo @ 2011-09-12 23:22 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-12 23:22 ` Rugxulo @ 2011-09-13 7:03 ` Ludovic Brenta 2011-09-13 7:55 ` Ludovic Brenta 0 siblings, 1 reply; 26+ messages in thread From: Ludovic Brenta @ 2011-09-13 7:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 7:03 ` Ludovic Brenta @ 2011-09-13 7:55 ` Ludovic Brenta 0 siblings, 0 replies; 26+ messages in thread From: Ludovic Brenta @ 2011-09-13 7:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-10 15:19 Does GNAT support a thread-free RTS? Simon Wright 2011-09-11 8:20 ` J-P. Rosen @ 2011-09-13 8:30 ` Simon Wright 2011-09-13 9:39 ` Georg Bauhaus 2011-09-13 10:57 ` Peter C. Chapin 1 sibling, 2 replies; 26+ messages in thread From: Simon Wright @ 2011-09-13 8:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 8:30 ` Simon Wright @ 2011-09-13 9:39 ` Georg Bauhaus 2011-09-13 12:18 ` Dmitry A. Kazakov 2011-09-13 10:57 ` Peter C. Chapin 1 sibling, 1 reply; 26+ messages in thread From: Georg Bauhaus @ 2011-09-13 9:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 9:39 ` Georg Bauhaus @ 2011-09-13 12:18 ` Dmitry A. Kazakov 2011-09-13 14:02 ` Robert A Duff 2011-09-13 16:54 ` Georg Bauhaus 0 siblings, 2 replies; 26+ messages in thread From: Dmitry A. Kazakov @ 2011-09-13 12:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 12:18 ` Dmitry A. Kazakov @ 2011-09-13 14:02 ` Robert A Duff 2011-09-13 16:35 ` Dmitry A. Kazakov 2011-09-13 16:54 ` Georg Bauhaus 1 sibling, 1 reply; 26+ messages in thread From: Robert A Duff @ 2011-09-13 14:02 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 14:02 ` Robert A Duff @ 2011-09-13 16:35 ` Dmitry A. Kazakov 0 siblings, 0 replies; 26+ messages in thread From: Dmitry A. Kazakov @ 2011-09-13 16:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 12:18 ` Dmitry A. Kazakov 2011-09-13 14:02 ` Robert A Duff @ 2011-09-13 16:54 ` Georg Bauhaus 2011-09-13 20:35 ` Dmitry A. Kazakov 1 sibling, 1 reply; 26+ messages in thread From: Georg Bauhaus @ 2011-09-13 16:54 UTC (permalink / raw) 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"? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 16:54 ` Georg Bauhaus @ 2011-09-13 20:35 ` Dmitry A. Kazakov 2011-09-13 21:22 ` Georg Bauhaus 0 siblings, 1 reply; 26+ messages in thread From: Dmitry A. Kazakov @ 2011-09-13 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 20:35 ` Dmitry A. Kazakov @ 2011-09-13 21:22 ` Georg Bauhaus 2011-09-14 7:58 ` Dmitry A. Kazakov 0 siblings, 1 reply; 26+ messages in thread From: Georg Bauhaus @ 2011-09-13 21:22 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 21:22 ` Georg Bauhaus @ 2011-09-14 7:58 ` Dmitry A. Kazakov 0 siblings, 0 replies; 26+ messages in thread From: Dmitry A. Kazakov @ 2011-09-14 7:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Does GNAT support a thread-free RTS? 2011-09-13 8:30 ` Simon Wright 2011-09-13 9:39 ` Georg Bauhaus @ 2011-09-13 10:57 ` Peter C. Chapin 1 sibling, 0 replies; 26+ messages in thread From: Peter C. Chapin @ 2011-09-13 10:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-09-14 7:58 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-10 15:19 Does GNAT support a thread-free RTS? Simon Wright 2011-09-11 8:20 ` J-P. Rosen 2011-09-11 9:22 ` John B. Matthews 2011-09-11 9:49 ` anon 2011-09-11 10:29 ` Pascal Obry 2011-09-12 0:33 ` anon 2011-09-12 7:27 ` Simon Wright 2011-09-12 9:26 ` Ludovic Brenta 2011-09-12 9:49 ` Ludovic Brenta 2011-09-13 1:22 ` anon 2011-09-12 13:01 ` Robert A Duff 2011-09-11 10:36 ` Simon Wright 2011-09-12 7:19 ` Ludovic Brenta 2011-09-12 23:22 ` Rugxulo 2011-09-13 7:03 ` Ludovic Brenta 2011-09-13 7:55 ` Ludovic Brenta 2011-09-13 8:30 ` Simon Wright 2011-09-13 9:39 ` Georg Bauhaus 2011-09-13 12:18 ` Dmitry A. Kazakov 2011-09-13 14:02 ` Robert A Duff 2011-09-13 16:35 ` Dmitry A. Kazakov 2011-09-13 16:54 ` Georg Bauhaus 2011-09-13 20:35 ` Dmitry A. Kazakov 2011-09-13 21:22 ` Georg Bauhaus 2011-09-14 7:58 ` Dmitry A. Kazakov 2011-09-13 10:57 ` Peter C. Chapin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox