Conference clt::cma

If it doesn't fit the spirit of what you are seeking, send mail to me and I'll
delete it.

Those who have been following this conference for a long time may be
particularly interested in item 2(B) below.

The easiest way to write correct threaded programs is to use a high-level
language with parallelism built in.  I'll describe the aspects of Ada here (not
a complete list, just the ones that come to mind first), and let others describe
other languages as appropriate.  By and large and in the main, as Dorothy Parker
might have put it, there is a 1-1 map from Ada tasks to threads.

Benefits:
  1. Reduced development time (a factor of 5-10 is probably typical).
  2. Greater reliability.  This benefit is huge: in some other conference the
study was cited which found that using a strongly typed language cuts errors per
line of code by about a factor of 25.  Also under this heading,
     A. Thread initialization and finalization are handled by the language.
     B. Uninitialized pointers don't exist, absent compiler bugs.
     C. Many race conditions are handled by the compiler and RTL.
  3. Performance (in Ada95, for some programs).  For the technical details as to
why protected objects use fewer context switches than monitors or semaphores,
see the Ada Rationale, section 9.1.3.

Costs:
  1. Performance (in Ada83, for some programs).  The 'rendezvous' is a nice
high-level paradigm, but for some simple sorts of problems is not performant
compared to simpler primitives.
  2. Ada95 on VMS isn't here yet (AVMS GNAT is in field test).

.1> If it doesn't fit the spirit of what you are seeking

Mike, this doesn't fit the spirit of what we are seeking.  :-)

But, we're not going to let you off the hook that easily!  Regardless of whether
someone chooses to use a language which provides direct support for
multiprogramming or whether s/he uses external support, such a person could
probably profit from the use of certain development tools.  You are claiming
that the compiler will take care of most of the problems.  Are you really
claiming that if we write in Ada we won't need a debugger, or a profiler, or
tracing or monitoring tools?  :-)

So, Mike, what tools would make your task (as Ada RTL implementor) easier, and
what tools would make the lives of Ada consumers better?


				Webb

>You are claiming that the compiler will take care of most of the problems.  Are
you really claiming that if we write in Ada we won't need a debugger, or a
profiler, or tracing or monitoring tools?  :-)

Actually, I didn't claim that directly, but if your phrase "the problems" is
defined to include all problems that *could* be encountered in the absence of
using the compiler, it's certainly true.  If 'could' is replaced by 'would',
it's *almost* certainly true, at least for medium to large programs.  To infer
the smiley-modified claim, though, would be invalid; there will always be
residual problems.  On the other hand, "need" is a relative term: most of the
Ada development I've done was with only a debugger, and often with one that was
flaky if tasking was used. And I had to walk 40 miles barefoot in the snow to
the office.

More seriously, the thing Ada users will want most is probably the ability to
deal with their programs in Ada terms, rather than (say) mentally translating to
C syntax when using the debugger.  It would be pleasant if the various tools
would tell exactly which threads were for Ada tasks and which weren't, and made
the mapping easy to deal with.

Your reply makes me think I need to read between the lines in .0.  Technical
input is likely to be wasteful of effort unless the non-technical constraints
are made explicit.  (That's not meant to be blunt or cynical; I'm not using
non-technical as a code word for 'political'.)  For example, would a request for
a very specific debugger feature fall into the realm of what you're looking for?

I agree that when a layered product is the one using threads then the
threads usage is more apt to be correct/efficient than if a random user
is using threads directly.  HOWEVER, we have certainly had a large
number of problem reports where the user didn't even know threads were
being used and we have had to debug thru layers of products (NOT easy).

But we need to develop tools to work for customers in whatever fashion
they choose to work - and for many customers, particularly the big
names (Banker's Trust, Alcatel, TRW, Bellcore, ...) they choose to use
threads directly.

> More seriously, the thing Ada users will want most is probably the ability to
> deal with their programs in Ada terms, rather than (say) mentally translating to
> C syntax when using the debugger.  It would be pleasant if the various tools
> would tell exactly which threads were for Ada tasks and which weren't, and made
> the mapping easy to deal with.

This is useful input (and a variation on a theme we have heard before and
are therefore considering).

> Your reply makes me think I need to read between the lines in .0.  Technical
> input is likely to be wasteful of effort unless the non-technical constraints
> are made explicit.  (That's not meant to be blunt or cynical; I'm not using
> non-technical as a code word for 'political'.)  For example, would a request for
> a very specific debugger feature fall into the realm of what you're looking for?

I agree - non-technical issues can be more important than technical.
We believe that we are taking those into consideration. (see above).

Our perspective is mainly remedial, some consultation, less development 
oriented so we were looking for broader input.

and yes, a request for a specific debugger feature would be seriously
considered (or at least passed on to the debugger group if that were
more appropriate).

Regards,
Jean