TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Content-Type: text/plain; charset=us-ascii
Sender: "Team Ada: Ada Programming Language Advocacy (83 & 95)" <[log in to unmask]>
From: Stephen Leake <[log in to unmask]>
Date: Thu, 17 Mar 2005 11:27:39 -0500
In-Reply-To: <[log in to unmask]> (Colin Paul Gloster's message of "Thu, 17 Mar 2005 11:39:43 +0100")
MIME-Version: 1.0
Reply-To: Stephen Leake <[log in to unmask]>
Parts/Attachments: text/plain (27 lines)
Colin Paul Gloster <[log in to unmask]> writes:

> Actually "task" is Ada's term for "process" not "thread". 

Hmm. In my experience, people use the term "process" for things that
have separate address spaces. Ada tasks share a single address space;
they can all access the same global variables. See ARM95 9 (8), and
ARM95 9.10.

> A process could have a number of subprocesses called threads which
> share data without mutual exclusion from the same process, like in
> POSIX or pthreads but thankfully not Ada.

Hmm. Ada permits two different tasks to access the same global
variable. If the global is declared Volatile, it can be safe. Ada also
provides higher-level abstractions for inter-task communication;
rendezvous and protected objects.

An Ada task is quite close to a POSIX pthread; the GNAT runtime uses
pthreads on platforms where it is available.

Ada allows programmers to shoot themselves in the foot; it just makes
it clear they are doing that :).

-- 
-- Stephe

ATOM RSS1 RSS2