Ada advocacy

[tonyg]

I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

[Ludovic Brenta]

tonyg wrote on comp.lang.ada:

Maybe you could start here: http://www.adaic.org/advantages/

--
Ludovic Brenta.

[Marc C]

On Tuesday, March 20, 2012 7:54:38 AM UTC-5, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA
> to some un named monstrosity of a language. Reasons listed are

<snip>
> programmers can not be found

This one is a pet peeve of mine. Has the project/company actually tried *looking* for Ada programmers? If they don't seek, of course they're not going to find. I regularly run into programmers who worked with Ada, liked it, but ended having to move onto other languages. Given the opportunity to go back to it, not a few would, they *just don't know of any available openings*!

And if an organization does deign to advertise, don't expect an Ada developer to take a 25% pay cut and move their family across the country just for the privilege. We're good engineers, dammit, recognizing talent and developing with Ada will get you a lot.

(Oh, and by what metric is Ada *2012* "archaic"? Python dates from 1989, C++ from 1979, and the likely monstrosity, Java, dates from 1991. The *youngest* of these is over 20 years old. Don't give me no "archaic" BS.)

Marc A. Criley
Ada sub-reddit moderator
(http://www.reddit.com/r/ada)

[Ludovic Brenta]

Marc C wrote on comp.lang.ada:

+1

Some more ammo:

http://qa.debian.org/popcon-graph.php?packages=gnat+gnat-4.1+gnat-4.3+gnat-4.4+gnat-4.5+gnat-4.6&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

This shows that the number of people using gnat on Debian is increasing.
The current number is approximately 1000 (blue line: installations of
the gnat-4.4 package). This is how many machines:

- run Debian (not a derivative like Ubuntu!)
- *and* have gnat-4.4 installed
- *and* enrolled in the Debian popularity contest
- *and* are connected to the internet.

The overall number of Ada programmers must be at least a couple
orders of magnitude larger.

--
Ludovic Brenta.

[Georg Bauhaus]

On 20.03.12 13:54, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

Do you have anything in your project for which there
is no ready made library in that other language?

Here's a sentence not to be said aloud:

Being a lemming reduces perceived risk.

[Yannick Duchêne (Hibou57)]

Le Tue, 20 Mar 2012 16:13:09 +0100, Ludovic Brenta
<lud...@ludovic-brenta.org> a écrit:

> Some more ammo:
>
> http://qa.debian.org/popcon-graph.php?packages=gnat+gnat-4.1+gnat-4.3+gnat-4.4+gnat-4.5+gnat-4.6&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> This shows that the number of people using gnat on Debian is increasing.

Does it count Ubuntu and others Debian derivatives users or strictly
Debian only?

--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[Yannick Duchêne (Hibou57)]

Le Tue, 20 Mar 2012 17:34:41 +0100, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:

> Does it count Ubuntu and others Debian derivatives users or strictly
> Debian only?

Sorry, you already answered in a forward sentence.

[Jeffrey Carter]

Quality is more important than age. Sure, Ada's been around since 1980, which is
longer than C++ (1982) or Java (early 1990s). But it's a better choice.

I know people who would like to use Ada but are unable to find positions using
it. If you advertise it, they will apply.

Where we have hard data (they are hard to come by), they show that development
in Ada takes 1/2 the effort of development in C. So a claim that "it takes too
long" is false.

--
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[Shark8]

On Tuesday, March 20, 2012 9:39:38 AM UTC-5, Marc C wrote:
> On Tuesday, March 20, 2012 7:54:38 AM UTC-5, tonyg wrote:
> > I am currently fending off an attempt to have my project converted from ADA
> > to some un named monstrosity of a language. Reasons listed are
> <snip>
> > programmers can not be found
>
> This one is a pet peeve of mine.

That is understandable; from the other direction though when *specifically* asking about Ada jobs/projects I get "No, we don't have anything like that" responses mostly. (The few Ada job postings that I have seen want prior-job experience, which I admittedly don't have, due to the former inability to find an Ada job.)

> Has the project/company actually tried *looking* for Ada programmers?

I think they don't.

> And if an organization does deign to advertise, don't expect an Ada developer to take a 25% pay cut and move their family across the country just for the privilege. We're good engineers, dammit, recognizing talent and developing with Ada will get you a lot.

Indeed, I think it may be the perception of progress/work. Ada forces a lot of work done up-front, which is starkly contrasted by languages like PHP (i.e. magic fairy-dust typing and error-apathy); oddly I think the fight-the-language/counteract-the-pitfalls contributes to the perception of work (but the thinking is directed at overcoming decencies of the language instead of solving the problem).

[an...@att.net]

The main problem is you have forgotten the golden rule the "Customer" or
group that is paying for the program sets the rules. If they say they
prefer non Ada then you should choose a language they like or they will
simply use someone else and you out of a job. Because most will say if
Microsoft does not support Ada, then we do not support Ada. And no matter
how many reasons you can give will every change most people minds.

In <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7>, tonyg <tonyt...@gmail.com> writes:
>I am currently fending off an attempt to have my project converted from ADA=
> to some un named monstrosity of a language. Reasons listed are ADA is arch=
>aic, programmers can not be found, it takes too long to develop blah blah l=
>ist goes on. Anyone got any glossy monosyllabillic advocacy documents hopef=

[Shark8]

On Tuesday, March 20, 2012 3:42:24 PM UTC-6, an...@att.net wrote:
> The main problem is you have forgotten the golden rule the "Customer" or
> group that is paying for the program sets the rules. If they say they
> prefer non Ada then you should choose a language they like or they will
> simply use someone else and you out of a job.

This is true; but how many customers actually care about the implementation language/platform? Unless it's extremely specialized (ie micro-controllers) or a windows application [specifically], that is.

> Because most will say if Microsoft does not support Ada, then we do not
> support Ada. And no matter how many reasons you can give will every change
> most people minds.

Microsoft *does* support Ada via its .NET platform... unless you want to argue that the "program in your preferred language" bullet-point touting .NET's advantages is false.

[Shark8]

On Tuesday, March 20, 2012 6:54:38 AM UTC-6, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

http://www.adapower.com/index.php?Command=Class&ClassID=AdvocacyVideos&Title=Ada+Advocacy+Videos

The videos are dated, talking about pre 95 revision, I think... but they make some good points... if I had talent on the drawing/artistic side I think it'd be fun to condence them into a cartoon format.

[Robert Love]

Good luck. I'm currently watching NASA throw away many 100K sloc of
Ada that's worked for 10 years to replace it with C++. It's being done
in the name of preparing for the future but really, I think it's a jobs
program, sad to say. The C++ guys sometimes sneer at Ada but we find
it funny that they haven't fully comprehended the scope of the problem
yet. I'm sure they'll get there eventually but as tax payers (if
you're US) it's very frustrating.

[Per Sandberg]

And some roumurs says: Thare are still small teams of programmers doing backports of some of the NASA C/C++ SW to Ada again, and they are finding "intresting" bugs that are repored back to NASA again.

[an...@att.net]

First, there is no "Microsoft Ada" or "Microsoft Visual Ada" for.net product.
Second, besides IBM z/OS Rational Apex Ada and Adacore GNAT there are no
other 2005 compilers. There are a few Ada 95 compiler but most software
companies like DEC, SGI, Sun have discontinued their Ada compilers. SGI
even suggest Adacore's GNAT.

So, Microsoft does not support Ada platform directly. And Microsoft does not
support any GNU language. Its GNU community that supports some Microsoft
platforms.

A reasons why people do not support Ada.

Microsoft has been using multi-threads since Windows 1.0 (DOS GUI addon)
which was shipped in early 1985 and with OS/2 1.0 a hardware based
intrinsic multitasking OS in 1987. So, when Microsoft went into the
schools, people learned that Windows was a multi-threading operating
system. And now every Microsoft language and OS platforms support parallel.

But, Ada has always been "Concurrent" aka DOS or batch like programming.
Aka no multi-threads or parallel design. Even in Ada 2012 (not adopted
yet), the parallel is not fully there only some simple multiple CPU
design structures.

Now, today, no software customer want to use a language unless that language
fully support multi-threading and parallel designs. So, until the ARG fully
embraces a true multi-threads parallel design, Ada will stay a limited usage
language.

[tonyg]

On Tuesday, March 20, 2012 12:54:38 PM UTC, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

Thanks for the help Guys. I'll let you know how it goes.

[KK6GM]

On Mar 20, 5:54 am, tonyg <tonytheg...@gmail.com> wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

A late reply, but I'd focus on two things. For management, I'd focus
on SAVING MONEY! Ada programs should field faster and require less
maintenence cost. Any manager who doesn't want to offer a better
product at a lower cost is a fool, or at least a problem for the
company.

For the programmers, I'd focus on the professionalism of (a) being
able to become fluent in new (to them) languages, and (b) using a
language that is demonstrably better than the language(s) they are now
using.

The latter point also applies to the "problem" of finding new
programmers. Any programmer who is looking for employment in a field
in which Ada is a suitable language choice, who won't or can't learn
Ada, is either incompetent (afraid he can't learn a new language), or
a prima dona (refuses to learn a new language), or myopic (incapable
of seeing that exposure to Ada will make him a generally better
programmer). In short, a programmer that you perhaps wouldn't want in
the first place.

Yes, these are all blanket statements that require modifying ifs, ands
and buts. But I think the facts support them. So it's up to you to
marshal those facts and form your arguments.

In summary, your job is to round up data to convince them that they're
brilliant if they continue to use Ada (and rewards will follow), and
idiots if they don't (and bad things will follow). :)

[Peter C. Chapin]

On 2012-03-21 01:37, Per Sandberg wrote:

> And some rumors says: There are still small teams of programmers

> doing backports of some of the NASA C/C++ SW to Ada again, and they
> are finding "intresting" bugs that are repored back to NASA again.

Those rumors might be pertaining to the CubeSat work we are doing at
Vermont Technical College. NASA is allowing us to use some navigation
software they developed. The software is written in C and, as C programs
go, is reasonably well done. We are working on converting it to SPARK...
a process that is ongoing. We have found a few "anomalies" so far---I'm
not sure I'd call them outright bugs---but we have only translated about
25% of the code and we are far from completing all the proofs.

Most of the programmers on this project are students and most of the
progress on it gets made during the summer.

Peter

[david]

On Tuesday, March 20, 2012 8:54:38 AM UTC-4, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

where are you located? I would welcome an opportunity to program in Ada.

[david]

On Tuesday, March 20, 2012 8:54:38 AM UTC-4, tonyg wrote:

> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

I would program in Ada in a NY second!

[johannes falcone]

>
> Good luck. I'm currently watching NASA throw away many 100K sloc of
>
> Ada that's worked for 10 years to replace it with C++.
>

> you're US) it's very frustrating.

NASA fails

[johannes falcone]

ada has tasklets and uses 16 cpu easily I heard..

[johannes falcone]

you should gather a few guys here and add them to the project working remote

kick butt

[tmo...@acm.org]

It's bizarre to watch the complaining about Chinese etc hackers, with nary
a mention of junky US software. Like a little pig continuing to build his
house of straw and squealing loudly when the big bad wolf blows it down.

[Leo Brewin]

Greetings,

I have just been reading some of the older posts in this discussion and came across the following objections to Ada (see quoted text below). Does anybody have any opinion on this? Is it correct? Is the original poster confusing the difference between a programming language and an operating system?

Cheers,
Leo

[Jeffrey Carter]

On 06/17/2013 05:14 PM, Leo Brewin wrote:
>
> I have just been reading some of the older posts in this discussion and came
> across the following objections to Ada (see quoted text below). Does anybody
> have any opinion on this? Is it correct? Is the original poster confusing the
> difference between a programming language and an operating system?

This is typical FUD from "anon" and like most of its posts can be ignored.

--
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

[Peter Brooks]

On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>
>
>         Ada was basically the first LANGUAGE that defined multi-tasking IN THE
> LANGUAGE itself. Before it, one had to use OS specific system calls to
> create tasks -- if such a call was even available, in contrast to creating
> processes at the command line level.
>
The second. Algol68 did.

[Robert A Duff]

Others, too. Per Brinch-Hansen's Concurrent Pascal, for example. It
has something-like Ada tasks (no rendezvous; no big loss), and
something-like Ada protected objects (without barriers -- that's
a big loss).

But Dennis is mostly right -- in the olden days, concurrency was mostly
considered an OS issue.

- Bob

[Bill Findlay]

On 18/06/2013 18:15, in article wccvc5b...@shell01.TheWorld.com,

"Robert A Duff" <bob...@shell01.TheWorld.com> wrote:

> Peter Brooks <peter.h....@gmail.com> writes:
>
>> On Jun 18, 3:28�am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>>>
>>>
>>> � � � � Ada was basically the first LANGUAGE that defined multi-tasking IN
>>> THE
>>> LANGUAGE itself. Before it, one had to use OS specific system calls to
>>> create tasks -- if such a call was even available, in contrast to creating
>>> processes at the command line level.
>>>
>> The second. Algol68 did.

Not to mention PL/I.

> Others, too. Per Brinch-Hansen's Concurrent Pascal, for example. It
> has something-like Ada tasks (no rendezvous; no big loss), and
> something-like Ada protected objects (without barriers -- that's
> a big loss).

Do you mean conditional critical regions?

They did have barriers, but Brinch Hansen and Hoare differed as to whether
they should be anchored at the start, e.g.:

region V await C do
...
end region;

or should be allowed anywhere inside the region construct:

region V do
...
await C;
...
end region;

--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;

[Robert A Duff]

Bill Findlay <yald...@blueyonder.co.uk> writes:

> Do you mean conditional critical regions?
>
> They did have barriers, but Brinch Hansen and Hoare differed as to whether
> they should be anchored at the start, e.g.:

I don't remember the details. Barriers in Ada are tied to the entry,
as opposed to being separate from the "monitor". And I seem to recall
some by-hand management of queues in Concurrent Pascal that is done
automatically in Ada. But my memory of Concurrent Pascal is hazy!

- Bob

[Bill Findlay]

On 18/06/2013 20:22, in article wcczjun...@shell01.TheWorld.com,

"Robert A Duff" <bob...@shell01.TheWorld.com> wrote:

Concurrent Pascal, specifically, only had "bad old" monitors.

CCRs were actually invented before Concurrent Pascal or Modula, so it was a
major disappointment that they were not included in either.

[nevil...@gmail.com]

On Tuesday, 18 June 2013 15:55:23 UTC+10, Peter Brooks wrote:
> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> >         Ada was basically the first LANGUAGE that defined multi-tasking
> > IN THE LANGUAGE itself.

> The second. Algol68 did.

c.f. http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#ALGOL_68
PAR ( # remove PAR for single threaded sort #
qsort(array[:i-1], cmp),
qsort(array[i+1:], cmp)
)

Blink and you might miss it! :-)

See also:
* http://rosettacode.org/wiki/Synchronous_concurrency#ALGOL_68
* http://rosettacode.org/wiki/Matrix_multiplication#Parallel_processing
* http://rosettacode.org/wiki/Generator/Exponential#ALGOL_68

The last example creates kind of a pipeline...

NJoy
NevilleDNZ

[johannes falcone]

so ada programs can use 16 core machines without special programming?

or must you pay for something non free like ravenscar?

or is ravenscar free?

[Jacob Sparre Andersen]

johannes falcone <vispha...@gmail.com> writes:

> so ada programs can use 16 core machines without special programming?

Yes. And 48 core systems. And even more if you can find them.

Greetings,

Jacob
--
"I Am The Leading Programmer" - J.-P. Rosen
is abstract tagged limited private

[Ludovic Brenta]

johannes falcone <vispha...@gmail.com> writes:
> so ada programs can use 16 core machines without special programming?

Correct.

> or must you pay for something non free like ravenscar?
> or is ravenscar free?

Ravenscar is free and is not a product, it is a specification of how you
can restrict Ada to a subset. In fact Ada itself is also a (language)
specification, not a product.

--
Ludovic Brenta.

[Shark8]

On Wednesday, June 19, 2013 1:34:23 PM UTC-6, Jacob Sparre Andersen wrote:
> johannes falcone <vispha...@gmail.com> writes:
>
> > so ada programs can use 16 core machines without special programming?
>
> Yes. And 48 core systems. And even more if you can find them.

Here's a 144-core chip; specially designed for [parallel] FORTH code.

[Yannick Duchêne (Hibou57)]

Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff
<bob...@shell01.theworld.com> a écrit:

Why did you said “no big loss” about the rendez‑vous? What's your known
issues with rendez‑vous? I never used concurrency a lot until now, so
that's really a question, because I may (or may not, I still don't know)
have to use it.


--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[Yannick Duchêne (Hibou57)]

Le Wed, 19 Jun 2013 09:29:57 +0200, <nevil...@gmail.com> a écrit:

> On Tuesday, 18 June 2013 15:55:23 UTC+10, Peter Brooks wrote:
>> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>> > Ada was basically the first LANGUAGE that defined
>> multi-tasking
>> > IN THE LANGUAGE itself.
>> The second. Algol68 did.
>
> c.f. http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#ALGOL_68
> PAR ( # remove PAR for single threaded sort #
> qsort(array[:i-1], cmp),
> qsort(array[i+1:], cmp)
> )
>
> Blink and you might miss it! :-)

And what happened to it? Was this all fine or not?

[Bill Findlay]

On 27/08/2013 14:34, in article op.w2g9br0kule2fv@cardamome, "Yannick

Duchêne (Hibou57)" <yannick...@yahoo.fr> wrote:

> Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff
> <bob...@shell01.theworld.com> a écrit:
>
>> Peter Brooks <peter.h....@gmail.com> writes:
>>
>>> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>>>>
>>>>
>>>> Ada was basically the first LANGUAGE that defined
>>>> multi-tasking IN THE
>>>> LANGUAGE itself. Before it, one had to use OS specific system calls to
>>>> create tasks -- if such a call was even available, in contrast to
>>>> creating
>>>> processes at the command line level.
>>>>
>>> The second. Algol68 did.

Just for histrical accuracy, I'll note that PL/I included language-defined
tasking in 1964.

[Bill Findlay]

On 27/08/2013 15:08, in article CE427152.35271%yald...@blueyonder.co.uk,
"Bill Findlay" <yald...@blueyonder.co.uk> wrote:

>
> Just for histrical accuracy, ...

That was meant to be "historical", not "hysterical" ...

[J-P. Rosen]

Le 27/08/2013 15:34, Yannick Duchêne (Hibou57) a écrit :
> Why did you said “no big loss” about the rendez‑vous? What's your known
> issues with rendez‑vous? I never used concurrency a lot until now, so
> that's really a question, because I may (or may not, I still don't
> know) have to use it.

It's a one person's opinion, that I certainly don't share.

Rendezvous are a high level concept, easy to use because close to what
you do in real life. Only those who think close to the bare machine have
issues with rendezvous. And don't forget a big plus of rendezvous over
protected objects: termination is (can be) automatic, without devising
some complicated handshaking.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[Maciej Sobczak]

> Why did you said "no big loss" about the rendez-vous? What's your known
> issues with rendez-vous? I never used concurrency a lot until now, so

> that's really a question, because I may (or may not, I still don't know)
> have to use it.

The biggest issue with rendez-vous is that it is (the server-side part of it) coupled by the rules of grammar to the top level of task body. That is, all your "accept" statements must be syntactically in the task body that declared appropriate entries.
It looks OK in the book examples, but since it makes code refactoring impossible, things can become ugly pretty quickly. This is kind of ironic, because rendez-vous is described as a high-level feature and high-level features normally add to code clarity. Here you have a high-level feature that is constrained by low-level grammar rules, hence the contradiction.

The "no big loss" statement is justified by the fact that rendez-vous does not offer anything particularly useful to what is already offered by protected objects.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

[Dmitry A. Kazakov]

On Tue, 27 Aug 2013 23:25:01 +0200, J-P. Rosen wrote:

> Le 27/08/2013 15:34, Yannick Duchêne (Hibou57) a écrit :
>> Why did you said “no big loss” about the rendez‑vous? What's your known
>> issues with rendez‑vous? I never used concurrency a lot until now, so
>> that's really a question, because I may (or may not, I still don't
>> know) have to use it.
> It's a one person's opinion, that I certainly don't share.
>
> Rendezvous are a high level concept, easy to use because close to what
> you do in real life. Only those who think close to the bare machine have
> issues with rendezvous. And don't forget a big plus of rendezvous over
> protected objects: termination is (can be) automatic, without devising
> some complicated handshaking.

Another plus is that rendezvous need not to be non-blocking and may include
lengthy actions.

Rendezvous could be easily extended on a distributed system, which would be
practically impossible for protected objects.

I think that for distributed and massively parallel systems rendezvous
clearly beat protected objects.

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

[Georg Bauhaus]

On 28.08.13 09:45, Maciej Sobczak wrote:
>> Why did you said "no big loss" about the rendez-vous? What's your known
>> issues with rendez-vous? I never used concurrency a lot until now, so
>> that's really a question, because I may (or may not, I still don't know)
>> have to use it.
>
> The biggest issue with rendez-vous is that it is (the server-side part of it) coupled by the rules of grammar to the top level of task body. That is, all your "accept" statements must be syntactically in the task body that declared appropriate entries.
> It looks OK in the book examples, but since it makes code refactoring impossible,

Having the accept statements in one place surely means
you'll find the server side's tasking interface and its
control structure (when acting), in one place.

Note that task can be nested; if bodies other that task bodies
could carry accept statements, that would be an invitation to create
very puzzling software designs. It'd take quite some effort to
find a task type's accept statements.

If, instead, scope is used for actions to go between acceptors,
private packages, separate, etc, then supporting definitions
can go elsewhere, and be refactored as needed, respecting the
needs of visibility of data. This leaves the communications parts
not scattered, but in one tight control struture.

I find this kind of grammatically required modularity normal for
a Has-It type language like Ada; I'd not expect this kind of
stricture when using a more "flexible" I-Can-Roll-My-Own language.

> The "no big loss" statement is justified by the fact that rendez-vous does not offer anything particularly useful to what is already offered by protected objects.

How so? There is no rendezvous via protected objects, since
using it means the program is using a different protocol.
And different types, different objects, likely different
places for shared data, and overall a different way of
communicating data. A handshake (rendezvous )and a mailbox
(PO) seem different to me.

Taken to the extreme of the Ravenscar profile, its lack of
rendezvous demonstrates the relative difficulty that ensues.

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 10:58:44 +0200, Georg Bauhaus wrote:

> On 28.08.13 09:45, Maciej Sobczak wrote:
>>> Why did you said "no big loss" about the rendez-vous? What's your known
>>> issues with rendez-vous? I never used concurrency a lot until now, so
>>> that's really a question, because I may (or may not, I still don't know)
>>> have to use it.
>>
>> The biggest issue with rendez-vous is that it is (the server-side part of
>> it) coupled by the rules of grammar to the top level of task body. That
>> is, all your "accept" statements must be syntactically in the task body
>> that declared appropriate entries.
>> It looks OK in the book examples, but since it makes code refactoring impossible,
>
> Having the accept statements in one place surely means
> you'll find the server side's tasking interface and its
> control structure (when acting), in one place.

The point Maciej does is valid and it is the issue which prevents tasks
from having entries proper methods supporting inheritance and overriding.

BUT, protected objects have problems with inheritance on their own as well
as problems with all other means of restructuring, refactoring, reuse etc.

It is unfair to blame tasks for something protected objects do not solve
either.

It is good that Ada has both tasks and protected objects. So far nobody
came with anything better, IMO.

[G.B.]

On 28.08.13 11:42, Dmitry A. Kazakov wrote:
> The point Maciej does is valid and it is the issue which prevents tasks
> from having entries proper methods supporting inheritance and overriding.

If that was the point, there still there is a huge difference
between "normal" types with overriding and all on the one hand
and task types on the other, namely that

task types specify possible orders of method execution (*)

That's the deal, a reference to an order of events in time,
right in the type. Something that ordinary types don't have.
(Except in the manner of trivial sequentiality of method
bodies.)

I suggest that saying "refactoring" is a far cry from being
a satisfactory solution of (*) from the language point of view.

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 13:42:16 +0200, G.B. wrote:

> On 28.08.13 11:42, Dmitry A. Kazakov wrote:
>> The point Maciej does is valid and it is the issue which prevents tasks
>> from having entries proper methods supporting inheritance and overriding.
>
> If that was the point, there still there is a huge difference
> between "normal" types with overriding and all on the one hand
> and task types on the other, namely that
>
> task types specify possible orders of method execution (*)

As well as other type could do in order to maintain the object's invariant.

BTW, this, no doubt, flawed idea is actively promoted by Ada 2012 idea of
preconditions <=> operations that are not applicable in *any* context where
arguments are valid.

As with plain types, one can argue that imposing certain order (as a
precondition) is merely bad design to be avoided when possible.

The corresponding patters for safer abstractions are sessions, transactions
etc, all in the end intended to weaken the preconditions.

> I suggest that saying "refactoring" is a far cry from being
> a satisfactory solution of (*) from the language point of view.

Refactoring *is* a solution, but the problem is that there is no good means
to refactor it easily, safely etc.

[G.B.]

On 28.08.13 13:59, Dmitry A. Kazakov wrote:
> The corresponding patters for safer abstractions are sessions, transactions
> etc, all in the end intended to weaken the preconditions.

These concepts not being defined in Ada, it is all the more worrying
that efforts in the direction of integrating such higher level
concepts are either

- hooked into closed source and/or patent pending algorithms/language
like e.g. into Google's experimental App Engine, or

- do not visibly produce any coordinated language design effort,
assuming the software-dependent industry ever thinks about such

An example of lack of coordination is reflected by OpenMP; the good
things developed with more recent versions of OpenMP still require
doubled (or squared) efforts when programming: both, the sequential
languages like C or Fortran, and the OpenMP capabilities, need to be
used properly. Paraffin cannot be much better than OpenMP here, I
think, since it's a library and needs convention, not language, for
expressing algorithms for Paraffin. When writing OpenMP annotations,
the mantra is likely "just do the right thing", again dismissing
language design in favor of proud, ego-full programmers who (think
they) do the right thing.

Do you think that current types can handle this at the language
level?

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 14:49:51 +0200, G.B. wrote:

> On 28.08.13 13:59, Dmitry A. Kazakov wrote:
>> The corresponding patters for safer abstractions are sessions, transactions
>> etc, all in the end intended to weaken the preconditions.
>
> These concepts not being defined in Ada,

It is not clear how to do that.

> it is all the more worrying
> that efforts in the direction of integrating such higher level
> concepts are either
>
> - hooked into closed source and/or patent pending algorithms/language
> like e.g. into Google's experimental App Engine, or
>
> - do not visibly produce any coordinated language design effort,
> assuming the software-dependent industry ever thinks about such

See above.

> Do you think that current types can handle this at the language
> level?

A [typed] language where synchronization primitives are first class objects
shall have this. Unfortunately nobody knows how.

[Eryndlia Mavourneen]

On Wednesday, August 28, 2013 9:07:34 AM UTC-5, Dmitry A. Kazakov wrote:
> On Wed, 28 Aug 2013 14:49:51 +0200, G.B. wrote:

> ...

> A [typed] language where synchronization primitives are first class objects
> shall have this. Unfortunately nobody knows how.

The compromise would seem to be the use of task interface types. These can be used to specify portions of code, which then can be combined into the desired task structure, including sequence, for specific needs.

-- Eryndlia (KK1T)

[Yannick Duchêne (Hibou57)]

Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.
<rm-dash-...@dash.futureapps.de> a écrit:

>
> That's the deal, a reference to an order of events in time,
> right in the type. Something that ordinary types don't have.

As a comment aside, that's why it happened I missed Ada had coroutines
(using a task in place of a coroutine is too much).

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 18:44:38 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.
> <rm-dash-...@dash.futureapps.de> a écrit:
>>
>> That's the deal, a reference to an order of events in time,
>> right in the type. Something that ordinary types don't have.
>
> As a comment aside, that's why it happened I missed Ada had coroutines
> (using a task in place of a coroutine is too much).

It is an interesting question, but too vague.

1. preemptive or not?

2. implicit state or explicit (bound to some object)

3. how much of the context where given execution path is nested would be
accessible?

4. inheritance issues

Maybe instead of coroutines... Ada does not specify whether tasks should be
native. What about providing tasks scheduled by the RTL (or user), in
addition to the native tasks, not as a replacement. Such tasks would have
many limitations regarding I/O, but no more coroutines would. And they will
be lighter than native tasks.

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 08:06:14 -0700 (PDT), Eryndlia Mavourneen wrote:

> On Wednesday, August 28, 2013 9:07:34 AM UTC-5, Dmitry A. Kazakov wrote:
>> On Wed, 28 Aug 2013 14:49:51 +0200, G.B. wrote:
>> ...
>> A [typed] language where synchronization primitives are first class objects
>> shall have this. Unfortunately nobody knows how.
>
> The compromise would seem to be the use of task interface types.

Interfaces never helped reuse (anything actually).

> These
> can be used to specify portions of code, which then can be combined into
> the desired task structure, including sequence, for specific needs.

This is already possible to do using procedures. Replacing them with
class-wide operations brings nothing. Less, actually, because class-wide
operations on interfaces could not access task object data.

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 19:33:23 -0400, Dennis Lee Bieber wrote:

> On Wed, 28 Aug 2013 19:25:59 +0200, "Dmitry A. Kazakov"
> <mai...@dmitry-kazakov.de> declaimed the following:

>
>>Maybe instead of coroutines... Ada does not specify whether tasks should be
>>native. What about providing tasks scheduled by the RTL (or user), in
>>addition to the native tasks, not as a replacement. Such tasks would have
>

> Of course, that implies that those tasks have no CPU time if their
> parent task/scheduler is suspended or blocked. It is the return of Windows
> 3 <G>

Yes, MS-DOS INT 13, if I correctly remember the number.

The main (only?) use case for co-routines is programming event-driven state
machines as if the I/O were blocking and not an asynchronous one
(completion event). E.g. socket-select stuff. GUI programming could also
use them is some cases (when the user must click through a sequence (tree)
of controls).

[Yannick Duchêne (Hibou57)]

Le Wed, 28 Aug 2013 19:25:59 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

> On Wed, 28 Aug 2013 18:44:38 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.
>> <rm-dash-...@dash.futureapps.de> a écrit:
>>>
>>> That's the deal, a reference to an order of events in time,
>>> right in the type. Something that ordinary types don't have.
>>
>> As a comment aside, that's why it happened I missed Ada had coroutines
>> (using a task in place of a coroutine is too much).
>
> It is an interesting question, but too vague.

Thanks for the interesting questions :)

> 1. preemptive or not?
No. Otherwise just use task.

> 2. implicit state or explicit (bound to some object)

Implicit. If explicit state is needed, it can be provided by other means.

> 3. how much of the context where given execution path is nested would be
> accessible?

Explicitly bounded.

> 4. inheritance issues
May be disallowed for dispatching operations.

> Maybe instead of coroutines... Ada does not specify whether tasks should
> be
> native. What about providing tasks scheduled by the RTL (or user), in
> addition to the native tasks, not as a replacement. Such tasks would have
> many limitations regarding I/O, but no more coroutines would. And they
> will
> be lighter than native tasks.

If you mean kind of green threads, I would say no, as I guess you mean
something pre‑emptive, and I mean something sequential with no
concurrency, like with sub‑program invocation in a single task.

There are ways to workaround it with actual Ada, but that's not handy.
There is the state machine which requires to flatten the conditional
structures in a case statement, and that does not help readability and
maintenance; sometime it comes as the most natural way to express things,
but not always.

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> writes:

> Why did you said “no big loss” about the rendez‑vous?

That's too big a topic to discuss in the margin of this message. ;-)
Just a few comments:

Protected objects can do almost everything rendezvous can do,
and I find protected objects to be more flexible.

The main thing I miss when using protected objects is the 'terminate'
alternative (as pointed out by J-P). The 'terminate' alt works only
with accept statements, not with entry calls. Also, you can do
multi-way waits with accept statements but not entry calls.
These things are a loss, but not a "big" loss. These limitations
of protected objects could be fixed, and then rendezvous would
be truly superfluous.

Suppose I have task A that wants to communicate with task B.
When programming in Ada 83, I usually found myself adding
another "passive" task in between A and B. Passive tasks
look something like this:

loop
select
accept E (...);
do stuff;
or
...
or
terminate;
end select;
end loop;

It just feels wrong to me for that to be a task. It's not
really doing anything; it's just sitting around waiting
to be told what to do -- like a protected object.
The "do stuff" above is likely some simple action
like putting data in a queue or taking it out.
A protected object seems better for that -- perhaps it's
"lower level", but it's the RIGHT level. And with a protected
object, you don't need a 'terminate' alternative in this case
-- protected objects just go away like any passive object
(say, an integer).

With rendezvous, one of the tasks must know about the other
(i.e. know its name), which increases coupling.

One ought to be able to split out pieces of code into
separate procedures -- that's an important tool for abstraction.
Any language design that inhibits that is questionable, IMHO.
As has been mentioned, accept statements must be lexically
within the task body, which damages this capability.

Rendezvous is a hugely complicated mechanism, which leads to
bugs, not to mention inefficiencies.

- Bob

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> writes:

> Why did you said “no big loss” about the rendez‑vous?

Here's an example based on something Tucker showed me that helped
convince me of the merits of protected objects over rendezvous:

protected P is
entry E1(...);
entry E2(...);
private
State: Enum := This_State;
end P;

protected body P is
entry E1(...) when State = This_State do
...
end E1;

entry E2(...) when State = That_State do
...
end E2;
end P;

In task T:

select
P.E1(...);
else
... -- (***)
end select;

P is always in one of two states: willing to do E1, and willing
to do E2. At (***), we know that at the moment P.E1 was called,
P was not willing to do E1, and was therefore willing to do E2.
It is impossible for P to be in a state where it is not willing
to do either E1 or E2. (A state visible to clients, I mean.)

It's not easy to program that using rendezvous. The passive
task has to (actively) loop back around to the select statement,
so there is a small window of time where neither 'accept' is
open. Small windows of time lead to subtle race conditions.

So you end up adding yet more task(s) to implement simple things
like locks. So using rendezvous tends to add complexity to
the program.

Using an active entity (a task) to program something that
should be passive (which is what you end up doing with
rendezvous) is an abstraction inversion. It's like killing
a gnat with a sledge hammer.

- Bob

[Dmitry A. Kazakov]

On Thu, 29 Aug 2013 16:47:04 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 28 Aug 2013 19:25:59 +0200, Dmitry A. Kazakov
> <mai...@dmitry-kazakov.de> a écrit:
>

>> 1. preemptive or not?
> No. Otherwise just use task.

I rather meant things like asynchronous system traps and task mailboxes.
I.e. when the task gets interrupted to perform some actions and then
continues. I believe an implementation would require distributed overhead
and rather poor latencies.

>> 3. how much of the context where given execution path is nested would be
>> accessible?
> Explicitly bounded.

Visibility of the context would meant additional overhead for switching
co-routines.

> There are ways to workaround it with actual Ada, but that's not handy.

Note really. It is impossible to convert callbacks into sequential code
without co-routines.

> There is the state machine which requires to flatten the conditional
> structures in a case statement, and that does not help readability and
> maintenance; sometime it comes as the most natural way to express things,
> but not always.

Yes, I don't consider this horror as a workaround.

[Jeffrey R. Carter]

On 08/29/2013 08:28 AM, Robert A Duff wrote:
>
> Also, you can do
> multi-way waits with accept statements but not entry calls.

You can do

select
P1.E1; -- An entry call.
then abort
P2.E4; -- Another entry call.
end select;

to wait for 1 of 2 entry calls, and you can nest another ATC in there to do 3, and so on to whatever depth you like, so
I don't really see a reason for the language not to provide a multi-way select for entry calls.

> It just feels wrong to me for that to be a task. It's not
> really doing anything; it's just sitting around waiting
> to be told what to do -- like a protected object.
> The "do stuff" above is likely some simple action
> like putting data in a queue or taking it out.
> A protected object seems better for that -- perhaps it's
> "lower level", but it's the RIGHT level. And with a protected
> object, you don't need a 'terminate' alternative in this case
> -- protected objects just go away like any passive object
> (say, an integer).

Sure. You should use a passive construct for a passive concept. One of Ada 83's problems was the lack of such a thing.
Ada 95 added the protected object, which partially solves the problem; however, sometimes you need mutual exclusion for
something that has to perform a potentially blocking action, and you can't use a protected object for that, so you're
back to using a task for something passive.

Some Ada-83 compilers, such as the DEC compiler, had "passive tasks", which were essentially protected objects without
functions and without the restriction on what they could do. I think standardizing that concept would have been a better
solution than introducing protected objects with their limitations.

--
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Jeffrey R. Carter]

That's not quite right. P can also be executing E1 or E2, in which case it is not "willing" to do either. T will end up
at (***) in both of those cases as well.

[johannes falcone]

Thank you for the info.

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrc...@spam.acm.org> writes:

> That's not quite right. P can also be executing E1 or E2, in which case
> it is not "willing" to do either. T will end up at (***) in both of
> those cases as well.

I don't think you mean "P can also be executing...", you mean "some task
can also be executing...".

But anyway, no, unless I'm missing something, there are only two
possible states. If some task is executing the body of P.E1, then P
must be locked. So if another task comes along and tries to call one of
the entries, it will try to lock P, and will not proceed until the first
task leaves E1. At that point, the second task will check the barrier[*],
and find it in one of the two possible states.[**]

The state "inside E1 or E2" is not an externally visible state,
so it doesn't really exist (from the clients' point of view).

In my previous message, I said that for the corresponding "passive task"
attempt to implement the same thing, the "will not accept E1 or E2"
state IS externally visible, because it could be going around the loop
back to the 'select'. But now you've reminded me that the same thing
happens if the passive task is inside one of the 'accept' statements.

[*]That's one way to think of it, but it doesn't really matter which
task checks the barrier and executes the entry body. In the so-called
"on behalf of" implementation model, the first task will do those things
on behalf of the second task, and then both tasks will proceed.

[**]Note that on a uniprocessor, the second task won't be running while
the first task is inside E1. The first task's priority has been raised
to the ceiling of P, and if the second is higher than that, that's a
ceiling violation.

- Bob

[Jeffrey R. Carter]

On 08/30/2013 09:54 AM, Robert A Duff wrote:
> "Jeffrey R. Carter" <spam.jrc...@spam.acm.org> writes:
>
>> That's not quite right. P can also be executing E1 or E2, in which case
>> it is not "willing" to do either. T will end up at (***) in both of
>> those cases as well.
>
> I don't think you mean "P can also be executing...", you mean "some task
> can also be executing...".

If we're going to use informal, active phrasing such as "P is willing" we can also say "P is executing" without fear of
misunderstanding.

> But anyway, no, unless I'm missing something, there are only two
> possible states. If some task is executing the body of P.E1, then P
> must be locked. So if another task comes along and tries to call one of
> the entries, it will try to lock P, and will not proceed until the first
> task leaves E1. At that point, the second task will check the barrier[*],
> and find it in one of the two possible states.[**]

That's even worse. Task T is delayed waiting for the other task to complete execution of P.E1, which can be a long time.
Those of us who are not language lawyers (especially those who started with Ada 83) expect a conditional entry call to
send the calling task to the else part immediately if the entry call cannot proceed. (Maybe that's not what the language
rules say, but that's how it's usually presented.) Once T sees that P is locked, it should go to the else part. If the
author of T were willing to be delayed waiting to get access to P, T would have used a timed entry call.

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrc...@spam.acm.org> writes:

> On 08/30/2013 09:54 AM, Robert A Duff wrote:
>> "Jeffrey R. Carter" <spam.jrc...@spam.acm.org> writes:
>>
>>> That's not quite right. P can also be executing E1 or E2, in which case
>>> it is not "willing" to do either. T will end up at (***) in both of
>>> those cases as well.
>>
>> I don't think you mean "P can also be executing...", you mean "some task
>> can also be executing...".
>
> If we're going to use informal, active phrasing such as "P is willing"
> we can also say "P is executing" without fear of misunderstanding.

Fair enough. You're right -- I didn't misunderstand you.

>> But anyway, no, unless I'm missing something, there are only two
>> possible states. If some task is executing the body of P.E1, then P
>> must be locked. So if another task comes along and tries to call one of
>> the entries, it will try to lock P, and will not proceed until the first
>> task leaves E1. At that point, the second task will check the barrier[*],
>> and find it in one of the two possible states.[**]
>
> That's even worse.

I don't think so. I'll try to explain why below.

>...Task T is delayed waiting for the other task to

> complete execution of P.E1, which can be a long time.

It can be, but it should not be. Entry bodies should be kept short
(at least in real-time systems, or other cases where such things
matter).

But in any case, it's what you want in this case -- task T must be
"delayed waiting" until the other task has (quickly, we hope) set the
state to one of the two possible states. We don't want it to see some
oddball intermediate state.

>...Those of us who

> are not language lawyers (especially those who started with Ada 83)
> expect a conditional entry call to send the calling task to the else
> part immediately if the entry call cannot proceed.

"Immediately" does not mean "in zero time". Not in Ada RM jargon,
anyway.

In the rendezvous case, the task doing the conditional entry call is
quite likely to take LONGER (in real time) to notice that the entry is
not open (than in the protected object case). And therefore longer to
jump to the 'else' part. I have implemented this stuff, and I know what
goes on behind the scenes -- there's (hidden) locking in the rendezvous
case, too, and yes that means that it can take some time to decide to
jump to the 'else'.

>... (Maybe that's not

> what the language rules say, but that's how it's usually presented.)
> Once T sees that P is locked, it should go to the else part.

That semantics doesn't seem like a good idea to me, because "P is
locked" means "P is in the middle of a state change". The whole point
of locking is to prevent clients from seeing that "in the middle" state.

>...If the

> author of T were willing to be delayed waiting to get access to P, T
> would have used a timed entry call.

A timed entry call with "delay 0.0" has identical semantics to a
conditional entry call. In both cases (rendezvous and protected
object), the calling task has to lock something before it can decide
whether the call can be done "immediately", and that locking takes
nonzero time.

Think about the semantics of a timed call with "delay
0.000_000_000_000_000_000_001".

- Bob

[Yannick Duchêne (Hibou57)]

Le Thu, 29 Aug 2013 23:43:30 +0200, Jeffrey R. Carter
<spam.jrc...@spam.acm.org> a écrit:

> Some Ada-83 compilers, such as the DEC compiler, had "passive tasks",

Via a representation pragma?

[Jeffrey R. Carter]

On 08/30/2013 03:41 PM, Robert A Duff wrote:
>
>
> In the rendezvous case, the task doing the conditional entry call is
> quite likely to take LONGER (in real time) to notice that the entry is
> not open (than in the protected object case). And therefore longer to
> jump to the 'else' part. I have implemented this stuff, and I know what
> goes on behind the scenes -- there's (hidden) locking in the rendezvous
> case, too, and yes that means that it can take some time to decide to
> jump to the 'else'.

That's surprising to learn, and useful to know.

The ARM-83 used the called task's place in its execution, as I recall: if the called task was at an accept for the
called entry, or at a select with an open alternative for the called entry, then the rendezvous took place; otherwise,
the calling task took the else part. ARM-95 changed that to whether the call was queued: if the call was queued at any
point, the call is canceled and the caller takes the else part; otherwise the caller remains in the select part.

[Jeffrey R. Carter]

On 08/30/2013 04:52 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 29 Aug 2013 23:43:30 +0200, Jeffrey R. Carter <spam.jrc...@spam.acm.org> a écrit:
>> Some Ada-83 compilers, such as the DEC compiler, had "passive tasks",
>
> Via a representation pragma?

Yes. I recall reading somewhere that the Ada-80 and -83 design team expected compilers to automatically recognize
passive tasks, and I recall reading papers on algorithms for doing so, but I think no actual compilers did so.

[Shark8]

On Friday, August 30, 2013 6:05:38 PM UTC-6, Jeffrey R. Carter wrote:
>
> Yes. I recall reading somewhere that the Ada-80 and -83 design team expected compilers to automatically recognize
> passive tasks, and I recall reading papers on algorithms for doing so, but I think no actual compilers did so.

That's very interesting.

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrc...@spam.acm.org> wrote in message
news:kvofa4$dnc$1...@adenine.netfront.net...

> On 08/29/2013 08:28 AM, Robert A Duff wrote:
>>
>> Also, you can do
>> multi-way waits with accept statements but not entry calls.
>
> You can do
>
> select
> P1.E1; -- An entry call.
> then abort
> P2.E4; -- Another entry call.
> end select;
>
> to wait for 1 of 2 entry calls, and you can nest another ATC in there to
> do 3, and so on to whatever depth you like, so I don't really see a reason
> for the language not to provide a multi-way select for entry calls.

The idea was extensively studied during the Ada 9x process, and the
conclusion was that it would be very expensive to implement. (I forget why,
but there should be papers on the topic somewhere in the Ada 9x documents.)
Moreover, the hard real-time users were the ones doing the lobbying for the
feature, and it was abundantly clear that they would not be able to use it
because of latency issues. (It certainly would have been excluded from
Ravenscar.)

Your workaround is also insanely expensive, but at least that is obvious
syntactically ("abort" should "feel" expensive to an Ada programmer in a way
that an entry call should not.)

Randy.

[Shark8]

On Friday, August 30, 2013 6:05:38 PM UTC-6, Jeffrey R. Carter wrote:
>

> Yes. I recall reading somewhere that the Ada-80 and -83 design team expected compilers to automatically recognize passive tasks, and I recall reading papers on algorithms for doing so, but I think no actual compilers did so.

I did a little searching and it appears that DEC Ada (on OpenVMS) did implement passive tasks; see this: http://odl.sysworks.biz/disk$vaxdocsep953/decw$book/d37aaa15.p142.decw$book

[Dirk Craeynest]

In article <adb155d2-cf6d-4db9...@googlegroups.com>,

Shark8 <onewing...@gmail.com> wrote:
>I did a little searching and it appears that DEC Ada (on OpenVMS) did
>implement passive tasks; see this:
>http://odl.sysworks.biz/disk$vaxdocsep953/decw$book/d37aaa15.p142.decw$book

FYI, in the late 80s early 90s, the Verdix Ada compiler (VADS) also
provided passive tasks and task types (via a pragma).

Dirk
Dirk.Cr...@cs.kuleuven.be (for Ada-Belgium/-Europe/SIGAda/WG9 mail)

*** 19th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2014
*** June 23-27, 2014 **** Paris, France **** http://www.ada-europe.org

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrc...@spam.acm.org> writes:

> The ARM-83 used the called task's place in its execution, as I recall:
> if the called task was at an accept for the called entry, or at a select
> with an open alternative for the called entry, then the rendezvous took
> place; otherwise, the calling task took the else part. ARM-95 changed
> that to whether the call was queued: if the call was queued at any
> point, the call is canceled and the caller takes the else part;
> otherwise the caller remains in the select part.

That's not really a change. If you stick to Ada 83 features, you
get the same behavior. The reason for the new wording is for
requeue (which is a handy feature).

- Bob

[Egil H H]

On Thursday, August 29, 2013 11:43:30 PM UTC+2, Jeffrey R. Carter wrote:
> You can do
>
>
>
> select
>
> P1.E1; -- An entry call.
>
> then abort
>
> P2.E4; -- Another entry call.
>
> end select;
>
>
>
> to wait for 1 of 2 entry calls, and you can nest another ATC in there to do 3, and so on to whatever depth you like, so
>
> I don't really see a reason for the language not to provide a multi-way select for entry calls.
>

There's a race condition here:
1. P1.E1 is not open, P2.E4 is open and starts to execute.
2. P1.E1 becomes open while P2.E4 is still executing.
3. P2.E4 is not aborted, as entries are abort deferred regions
4. P1.E1 and P2.E4 is both executed and run to completion.

[G.B.]

Assuming that P1 and P2 are POs (or passive tasks), there is
just one program counter applying to both. Won't this
prevent P1 and P2 from running at the same time?

[Egil H H]

On Monday, September 2, 2013 10:41:02 AM UTC+2, G.B. wrote:
>
> Assuming that P1 and P2 are POs (or passive tasks), there is
>
> just one program counter applying to both. Won't this
>
> prevent P1 and P2 from running at the same time?

An asynchronous select statement may be executed concurrently,
or even in parallel on a multi-processor platform.
(and it is with Gnat on Linux)

[Martin]

Third (at least)...

Pascal/D80 for Ericsson's D80 processor...developed by Ada's own John Barnes!

My first "pro" job used this...fantastic language, fantastic tools and a fantastic processor. 25 years later and we're just about at the same context switch speed on PowerPC/i7 boards.