From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 28 Aug 91 02:50:48 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: re-use and concurrency
Message-ID: <EACHUS.91Aug27195048@Dr_No.mitre.org>
List-Id: <comp.lang.ada>

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...