TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding: quoted-printable
Sender: "Team Ada: Ada Programming Language Advocacy (83 & 95)" <[log in to unmask]>
From: Peter Amey <[log in to unmask]>
Date: Tue, 7 Dec 2004 08:24:22 -0000
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Reply-To: Peter Amey <[log in to unmask]>
Parts/Attachments: text/plain (33 lines)
> -----Original Message-----
> From: Team Ada: Ada Programming Language Advocacy (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Joyce L. Tokar
> Sent: 06 December 2004 20:25
> To: [log in to unmask]
> Subject: Re: Question #2
> On Mon, 6 Dec 2004 09:47:22 -0500, David Botton wrote:
> >Ok #2 in our series of questions that will make their way in to the
> >FAQ, articles, etc. (I will be putting together #1 answers soon)
> >
> >Why is it better to have tasking as a language feature than 
> as an API?
> >
> >

There is another advantage, from our rather parochial corner of Ada world: making something part of the language makes it possible to subset and annotate it as part of a language like SPARK.  By doing so we are able to create an environment in which certain properties of a concurrent system, such as freedom from priority inversions, can be statically proved. If the underlying task constructs were not part of the language we would not be able to achieve this rather useful goal.

Even the foundations on which are work is built, the Ravenscar profile, would not be possible if the language's attitude to concurrency was "roll your own threads using operating system primitives".



This email is confidential and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited.  If you have received this email in error please contact the sender.  Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis High Integrity Systems Ltd (Praxis HIS). 

 Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis HIS or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.  The IT Department at Praxis HIS can be contacted at [log in to unmask]