From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,HEADER_SPAM, INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:5757 comp.parallel:2683 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!sol.ctr.columbia.edu!emory!hubcap!fpst From: telesoft!rlk@uunet.UU.NET (Bob Kitzberger @sation) Newsgroups: comp.lang.ada,comp.parallel Subject: Re: Ada rendenzous overhead Keywords: Ada,rendezvous Message-ID: <1991Jun21.120837.5434@hubcap.clemson.edu> Date: 20 Jun 91 19:32:17 GMT References: <1991Jun17.170630.3057@hubcap.clemson.edu> Sender: fpst@hubcap.clemson.edu (Steve Stevenson) Organization: TeleSoft, San Diego, CA, USA To: uunet!comp-parallel@uunet.UU.NET List-Id: Tony Sterrett writes: > Does Anyone have any information regarding the > overhead for Ada rendenezvous in a parallel environment? I would suggest getting in touch with your vendor and asking for any benchmarks related to tasking, specifically: PIWG C/T tests (PIWG :== Performance Issues Working Group) Hartstone test (from SEI, real-time applicability) Rendezvous are much lighter weight than full-blown processes (kind of a fore-runner of the current fashionable 'lightweight threads' POSIX and Unix-ish mechanisms). Don't be too surprised if you start seeing rendezvous implemented on top of OS-supported lightweight threads, especially in multi-processor Unix environments. .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 -- =========================== MODERATOR ============================== Steve Stevenson {steve,fpst}@hubcap.clemson.edu Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell