TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Content-Transfer-Encoding:
7bit
Sender:
"Team Ada: Ada Programming Language Advocacy (83 & 95)" <[log in to unmask]>
Subject:
From:
Alan and Carmel Brain <[log in to unmask]>
Date:
Sun, 19 Sep 2004 00:24:15 +1000
Content-Type:
text/plain; charset="iso-8859-1"
MIME-Version:
1.0
Reply-To:
Alan and Carmel Brain <[log in to unmask]>
Parts/Attachments:
text/plain (30 lines)
From: "ljknews" <[log in to unmask]>

> At 12:10 PM +0100 9/18/04, Simon Wright wrote:
>
> >It's certainly true that the (apparent) ease of task programming in
> >Ada can lead new users to think that they can use tasks without
> >considering the resource usage. If you had 1000 radar tracks, it might
> >be unwise to assign a task to each one; at the very least, you'd want
> >to measure the performance in the prototype phase.
>
> There ain't no such thing as a free lunch, and those who believe
> otherwise are bound for a life of disappointment.
> --
> Larry Kilgallen

On the other hand, I've seen projects fail because 'clever' and non-trivial
software techniques had to be used. After a decade of debugging, the damn
things still didn't work. Worse, the option was available of just waiting
18 months for a faster processor that would make a brain-dead simple software
solution feasible.
This is emphatically not always the case, but the larger the system, the
more probable it becomes.

I admit that a kilotrack system with one task per track gives me pause,
no matter how simple it is conceptually, or how low the task overhead is
"according to the manual". Test it first as a risk-reduction measure, and
at a very early stage in the architectural design.

"it might be unwise" indeed.

ATOM RSS1 RSS2