Re: OT: Politics of Java
On Sat, Dec 14, 2002 at 08:46:43PM -0800, Craig Dickson wrote:
> Yes, but the question is, how usable is it in practice?
[snip]
People use "tasks" in Ada on a regular basis. So, it must be usable,
neigh?
> I have never learned Ada, partly because I've never needed to and
> partially because it's never attracted my interest, in part due to its
> reputation as "the PL/I of the '80s" (translation: a vastly overcomplex,
I've been recently attracted to Ada due to its ability to catch many
more errors at compile time than C (meaning, less bug hunting). I was
shocked when I first started using it how many things the compiler
would complain about. One tricky bit is the visibility rules, esp.
in relationship to operators. Anyway, I think it is much maligned
simply as a reaction to its origin w/ the US DOD or because of its
Pascal'ish syntax.
From chapter 9 of the Ada95 Reference Manual w/ Tech. Corrigendum 1:
(http://www.adaic.com/standards/95lrm/html/RM-TTL.html)
Section 9: Tasks and Synchronization
1
The execution of an Ada program consists of the execution of one or
more tasks. Each task represents a separate thread of control that
proceeds independently and concurrently between the points where it
interacts with other tasks. The various forms of task interaction
are described in this section, and include:
2
* the activation and termination of a task;
3
* a call on a protected subprogram of a protected object, providing
exclusive read-write access, or concurrent read-only access to
shared data;
4
* a call on an entry, either of another task, allowing for synchronous
communication with that task, or of a protected object, allowing for
asynchronous communication with one or more other tasks using that
same protected object;
5
* a timed operation, including a simple delay statement, a timed entry
call or accept, or a timed asynchronous select statement (see next
item);
6
* an asynchronous transfer of control as part of an asynchronous select
statement, where a task stops what it is doing and begins execution
at a different point in response to the completion of an entry call
or the expiration of a delay;
7
* an abort statement, allowing one task to cause the termination of
another task.
8
In addition, tasks can communicate indirectly by reading and
updating (unprotected) shared variables, presuming the access is
properly synchronized through some other kind of task interaction.
Static Semantics
9
The properties of a task are defined by a corresponding task
declaration and task_body, which together define a program unit
called a task unit.
Dynamic Semantics
10
Over time, tasks proceed through various states. A task is initially
inactive; upon activation, and prior to its termination it is either
blocked (as part of some task interaction) or ready to run. While
ready, a task competes for the available execution resources that it
requires to run.
NOTES
11
1
Concurrent task execution may be implemented on multicomputers,
multiprocessors, or with interleaved execution on a single physical
processor. On the other hand, whenever an implementation can
determine that the required semantic effects can be achieved when
parts of the execution of a given task are performed by different
physical processors acting in parallel, it may choose to perform
them in this way.
--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler
Reply to: