Re: re-use and concurrency

Re: re-use and concurrency

[Jim Showalter]

brossard@sic.epfl.ch (Alain Brossard EPFL-SIC/SII) writes:

[stuff aout Booch Components in Ada vs C++ deleted]

>To me it looks like Ada is losing big to C++...

Well, it seems rather simplistic to me to decide that one language
is inferior to another because it lacks inheritance. If it is
valid to seize on a single language feature as the sole basis for
comparison, why not beat up on C++ for lacking concurrency support?
Surely concurrency is as necessary to developing software as
inheritance? Or do you live in a world with only one thread?

Furthermore, there are all sorts of other things C++ lacks that
Ada has, none the least of which is a standard definition and
compiler validation. To ignore issues like this and focus exclusively
on inheritance does a disservice to those who are trying to wade through
the hype to make an informed language choice.
-- 
* Jim Showalter, software engineering consultant *
*         e-mail: jls@netcom.com                 *
*         voice : (408) 243-0630                 *
*         data  : (408) 984-5019                 *

Re: re-use and concurrency

[sdd.hp.com!spool.mu.edu!cs.umn.edu!sctc.com!stachour]

brossard@sic.epfl.ch (Alain Brossard EPFL-SIC/SII) writes:
  ... Size of Concurrent versus size of Sequential statements ...
>    Even if we assume that the concurrent version was twice
>the size of the sequential version, we are still looking at
>50'000 lines of Ada vs 20'000 lines of C++.  That means
>30'000 more lines to maintain (not to mention the duplication
>involved in having two versions of each components which is an issue
                   ^^^^^^
>in itself!).  To me it looks like Ada is losing big to C++...

Monsieur Brossard (et autres):

Nope. Not really. What is not widely known in the programming community 
is that there is not just "one" version of non-sequentiality.  In his book,
beginning on page 188, Grady indicates concurrency variations as:
  
    Sequential (serially reusable, hopefully no explanation needed)
    Guarded (where clients are responsible for call in correct context)
    Concurrent (where clients can call "any old time", but where only
        one task is in the "package" as one time)
    Multiple (where multiple clients can be executing the package
        simultaneously, like from multiple CPUs on shared data)

[There are other variants of concurrency, such as non-rexecutable and 
others, but I have shown only Grady's taxonomy to simplify the issue,
and give a generally available reference for others to consult.
The other variants are mostly uninteresting.]

So the right-number is not twice-as-much function, but 4-times-as-many.
And from my own experience, the multiple variant is extremely difficult.

[I have never seen, in any book on concurrency, data-structures, etc.,
written by any compotent author, including Booch, a program (that runs 
on generally available hardware) that implements a multiple-concurrency
doubly-linked list datastructure.  I have seen "solutions" by naive
authors who ignore parts of the multiple concurrency issue that
portend to run correctly; I have found at least one race-condition the
negates the proposed "solution" in every one that I have analyzed.  
Now, I don't therefore assert that it is impossible 
(I have no formal proof), but very hard and maybe not possible.]

And if one wants to ignore the concurrency issues, then software can
get pretty easy (by comparision).  Grady's win is that he defines for
us packages, with similar (and in most cases identical) interfaces for
both sequential and all varieties of concurrency.  Thus, when you discover
that you have a concurrency issue, you are allowed to make the time/
space/correctness tradeoff without having to rewrite gobs of code to
account for the concurrency needs.  

Thanks, Grady, for providing a good taxonomy of concurency for us.
Thanks, Ada, for giving me means to implement and use concurrency well.


...Paul

Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112-3739
                             [1]-(612) 482-7467
-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112-3739
                             [1]-(612) 482-7467

Re: re-use and concurrency

[Bob Kitzberger @midnight]

In <1697@sicsun.epfl.ch> brossard@sic.epfl.ch (Alain Brossard EPFL-SIC/SII) wri
tes:


>    Specificaly, suppose you are re-using a stack package and
>create a really usefull package out of this.  Next week/month/year,
>another collegue wants to re-use your neat package and doesn't
>realize there is this hidden requirement to be sequential.
>    
>    To me it seems the only solution would be to design
>every package to be "concurrent" proof.  What is the cost
>of such a decision?

If the solution involves using a task to implement something like
a Hoare monitor to serialize access to the package, then the cost is 
that the compiler's tasking support must be linked into the executable 
image regardless of whether or not the application is concurrent.
In addition, there is the run-time overhread of performing rendezvous
to implement the monitor.

Wrapping a task around a package to act as a monitor is as simple
as can be.  Personally, I'd leave the package libraries serial, and
if I need them to handle concurrency then I'd wrap a task around them
as needed.

	.Bob.
-- 
Bob Kitzberger               Internet : rlk@telesoft.com
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA  92121-9891  (619) 457-2700 x163
------------------------------------------------------------------------------
package body Disclaimer is separate;

Re: re-use and concurrency

[mintaka!ogicse!hsdndev!encore!jcallen]

Various people have discussed the problem of needing "sequential" and
"concurrent" implementations of reusable components. Not only are multiple
implementations needed, but you also have to decide which one to use.
While this might seem easy, what if you are building yet another component
that may be used in either tasking or non-tasking programs?

Seems to me the right way to solve this is with the library manager;
put the "sequential" and "concurrent" implementations in separate libraries
and them select the one you need at link time. This does require that your
compiler's library scheme allow specs and bodies in different libraries,
and that the set of libraries used be changable at link time. I know
that (at least) the Intermetrics, Rational and Verdix compilers will
allow this, with varying levels of kluginess.

What would REALLY be nice is to have the linker select the right library
for you, based upon whether or not tasking is in use. Some linkers already
know if tasking is present, so such automatic library selection SHOULDN'T
be a difficult thing to offer, eh?

-- Jerry Callen
   jcallen@encore.com

Re: re-use and concurrency

[Robert I. Eachus]

In article <16575@encore.Encore.COM> jcallen@Encore.COM (Jerry Callen) writes:

   Seems to me the right way to solve this is with the library manager;
   put the "sequential" and "concurrent" implementations in separate libraries
   and them select the one you need at link time...

   What would REALLY be nice is to have the linker select the right library
   for you, based upon whether or not tasking is in use. Some linkers already
   know if tasking is present, so such automatic library selection SHOULDN'T
   be a difficult thing to offer, eh?

   Make anything you build as simple as possible...but not simpler.
Unfortunately software is NEVER simple, and when you care about
selecting components the choices have to be based on considerations
that no linker or library manager can be trusted with.  For example,
even in a tasking environment some resources will be managed by a
single task at any one time, so you want (and in a real-time
environment NEED) to use a sequential implementation.  Since it is
often the case in such systems that several tasks actually use the
package, a compiler can't figure it out without the design documents.
(For example, one task creates all the structures then starts up other
tasks which use them.  Happens all the time in real-time systems.)

   There is also a problem with your suggestion to select different
implementations at link time.  In many cases this is possible, and Ada
environments do support it.  However, in some cases the various
implementations must have different interfaces for the different
regimes.  Unfortunately, this happens all over the place with tasking.
For example, you often need to export the fact that a call is to a
task entry so that the user of the package can choose what type of
call to make.

   Another problem is more subtile: the interface may look the same
but you have to use it differently.  For example, a call to a
(tasking) queue when the queue is empty may not raise an exception, it
will just wait.  However, checking to see if the queue is empty before
making the call is no help.  In the sequential implementation, the
opposite is true.


--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...