Re: re-use and concurrency

[sdd.hp.com!spool.mu.edu!cs.umn.edu!sctc.com!stachour@ucsd.edu (Paul Stac]

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