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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78546269947cb927 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-29 15:14:43 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!news.moat.net!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 29 Mar 2004 17:14:43 -0600 Date: Mon, 29 Mar 2004 18:14:42 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Combining entry_call, accept_statment and terminate_statment References: <106h7clrs4iio8c@corp.supernews.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.128.39.153 X-Trace: sv3-0LBoEpGT/zEthF+5W38eoxkp7377rSCoxMaP412HVXmdOF3QuptBj+AEPoekqtpODfcHp4SnJ+MJ+sS!vtd2W9Zuq4k2J5uhbA0J7bDe6F2zgbc5skOVYK9MVbzRydVcE29ZwLoWsgya+A== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:6661 Date: 2004-03-29T18:14:42-05:00 List-Id: Mark Lorenzen wrote: > "Randy Brukardt" writes: > > [cut] > > >>But I'd say that you probably have a design problem if you have a task that >>is both calling and accepting at the same time. That's pretty weird (unless >>the accepts are purely for task control, as above). It's preferable that >>each task be either a server (accepting entries) or a client (calling >>entries), but not both. Analysis is complicated if you have both. >> >> Randy. > > > To me, this seems to be a severe design limitation. Isn't it normal to > have a task acting as a filter, i.e. reading data from a PO, > manipulating the data and the writing the manipulated data to a PO? > This could f.x. be a task implementing a (de)multiplexer. > > - Mark Lorenzen I was going to say that the special case of a "transformer" that accepts a call and then immediately makes a call, usually in a loop is an exception to this rule. But you beat me to it. If you create a call graph for tasks and protected objects each node should either make calls or be the target of calls, with this one exception where the net number of calls is always negative. If you want to think of these special cases as arcs instead of nodes, that works too. Oh, and there is a different exception which is seldom used. You may requeue a call to you as a call to a different entry (common) or to an entry of another task. I have no idea of how to represent or analyze that last case. -- Robert I. Eachus "The terrorist enemy holds no territory, defends no population, is unconstrained by rules of warfare, and respects no law of morality. Such an enemy cannot be deterred, contained, appeased or negotiated with. It can only be destroyed--and that, ladies and gentlemen, is the business at hand." -- Dick Cheney