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: 17 Aug 91 04:37:57 GMT From: telesoft!rlk@uunet.uu.net (Bob Kitzberger @midnight) Subject: Re: re-use and concurrency Message-ID: <1991Aug17.043757.7181@telesoft.com> List-Id: 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;