Re: Teaching new tricks to an old dog (C++ -->Ada)

["jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>]

CTips wrote:
> Jim Rogers wrote:
>
> > CTips <ctips@bestweb.net> wrote in
> > news:112sonip5v4dca6@corp.supernews.com:
> > If you want different scheduling policies you write them, just as
> > in C or C++.
>
> Right - and then what's the advantage of the built-in features of Ada

> over and
>

The advantage of the built-in features are that they are a very
good implementation of a tasking model. You seem to have two
standards. C is good because you can do what you want while
Ada is bad because it does not do everything for you.

> > How, using C or C++, would you create a threaded program and
> > ensure that signals are handled by a specified thread, and not
> > simply by the thread that is currently running when the signal
> > is received?
>
> What do you mean "handled by a thread"? How can you distinguish which

> thread is actually interrupted? More importantly, why do you care?

I mean, how do you determine which thread actually does the
actions to respond to a signal? Signals are asynchronous. You cannot
predict which thread will be executing when the signal is received.
You can determine which thread does the work of responding to
a signal.

Ada treats signals (or, as they call them, interrupts) as
a form of asynchronous thread communication. Since Ada 95, all
Ada interrupt handling has been handled in the following manner.

A protected object is created to receive the interrupt.
Ada provides pragmas to designate the protected object as
an interrupt receiver, and to associate a particular signal
with the protected object. You typically want a protected object
with a parameter-less procedure and an entry.

protected handler is
   procedure Set;
   entry Release;
   pragma Interrupt_Handler(Set);
   pragma Attach_Interrupt(Set, SIGINT);
private
   Counter : Natural := 0;
end handler;

protected body handler is
   procedure Set is
   begin
      Counter := Counter + 1;
   end Set;
   entry Release when Counter > 0 is
   begin
      Counter := Counter - 1;
   end Release;
end handler;

Using the example above:

A task is created to handle the interrupt.
That task calls Release and is suspended because the condition
evaluates to FALSE.

When the designated signal is received the procedure Set is
called, causing Counter to be incremented. This immediately
changes the condition on the Release entry, causing the
counter to be decremented and the suspended task to be scheduled.

This ensures that only the task I have designated actually handles
the interrupt, and that the interrupt handling behaves exactly like
any other task in the system.

>
>   However, in POSIX, you can do it by using pthread_sigmask() to
disable
> delivery of the signal to all threads other than the handling one.
>
> > You seem to assume that Ada only allows you to use features
> > provided by the language while preventing you from creating
> > your own features. That idea just doesn't make any sense.
>
> Nope, I didn't say that - what I said was that Ada (particularily the

> concurrent part of Ada) is fairly retarted, particularily if you want
to
> get performance. In fact, to get the performance similar to that
which
> can be obtained in C, one would pretty much have to write in the C
> subset of Ada [i.e. turn off most of the checking, use libraries
written
> in C + asm]. And even there I'd have my doubts - given the additional

> features that Ada compilers have to deal with, I doubt that they
would
> have focused as much on the optimizations.

Interesting. Ada compilers written for a POSIX compliant system
usually implement concurrency through the POSIX libraries.
Ada compilers written for other systems, such as WIN32 implement
their concurrency using the thread libraries native to that
system. It is extremely easy to call C libraries from an Ada
program.

The primary advantages of the Ada approach are that concurrency
is implemented natively when the OS supports threads, and the
Ada source code is highly portable from one system to the other.
The only non-portable features will be the names of interrupts
across systems.

> > Linked lists are not implemented as native syntax in either
> > Ada or C, yet they are used frequently in both languages.
> > How can that be?
>
> And their C implemenations are faster.

Is that true in all cases? I suspect not.
For instance, I responded to a thread on Comp.Programming
concerning an algorithm to identify the first bit set in
a 32 bit integer. My Ada solution, in its worst case, runs
in about 3 microseconds on a WIN XP system, and I do a
linear search of the bits.

Jim Rogers