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 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 14:05:10 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Combining entry_call, accept_statment and terminate_statment
Date: Mon, 29 Mar 2004 16:04:49 -0600
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <106h7clrs4iio8c@corp.supernews.com>
References: <slrnc6guve.g7p.lutz@belenus.iks-jena.de>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Complaints-To: abuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:6659
Date: 2004-03-29T16:04:49-06:00
List-Id: <comp.lang.ada>

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnc6guve.g7p.lutz@belenus.iks-jena.de...
> Unfortunly this is not allowed. Either accept and terminate or an
entry_call
> and a delay can be combinded. I wonder how to solve such as deadlock. It
> should be a common idiom, but I had no luck in choosing searching
keywords.

I can't tell you how to work around it, but I can tell you why it's not
allowed - the implementation would be very slow.

During the Ada 9X process, there was a proposal for a multi-way entry call.
(A more limited version of what you're asking for here.) The three
User-Implementer teams were asked to analyze the implementation effort. (The
reports are somewhere in the AdaIC archives, if you're interested.) All
three teams decided that the run-time cost of the feature would be high (it
would be close to polling). Since the real-time users that were requesting
the feature need high performance, it was eventually dropped as impractical.

I recently ran into a similar problem. All I wanted was an entry call with
terminate. The (ugly) solution I used was to add an explicit Quit entry to
the task, and I changed the select into a polling loop:

    loop
         select
             accept Quit;
             exit;
         else null;
         end select;
         select
             PO.Get_New_Operation (...);
             Do_Operation (...);
         or
             delay 0.06;
         end select;
    end loop;

That's effectively what the implementation of such a select would have to do
anyway, so there's not much extra cost.

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.