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 23:29:02 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!newsfeed.stueberl.de!news-FFM2.ecrc.net!news.iks-jena.de!not-for-mail From: Lutz Donnerhacke Newsgroups: comp.lang.ada Subject: Re: Combining entry_call, accept_statment and terminate_statment Supersedes: Date: Tue, 30 Mar 2004 07:29:01 +0000 (UTC) Organization: IKS GmbH Jena Message-ID: References: <106h7clrs4iio8c@corp.supernews.com> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1080631741 26176 217.17.192.37 (30 Mar 2004 07:29:01 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Tue, 30 Mar 2004 07:29:01 +0000 (UTC) User-Agent: slrn/0.9.8.0 (Linux) Xref: archiver1.google.com comp.lang.ada:6666 Date: 2004-03-30T07:29:01+00:00 List-Id: * Randy Brukardt wrote: > "Lutz Donnerhacke" wrote in message >> 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. IBTD. accept_statements and entry_call_statements as well as the terminate_statement deal with queuing (wait queues). AFAIK the linux kernel does implement all such "select" constructs by such wait queues and does not have much trouble with it. Of course accept and terminate queues are the other way around than entry calls. > 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 do see the problem now: entry_barriers on entry_calls to protected types or guarded task accepts are evaluated by the calling task. Therefore wait queues are not possible. Polling is required. This explains an other problem, I came across: > 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 exactly my current implementation. But I increased the delay and noticed, that the entry_barrier of the delayed entry_call is evaluated only once on startup of the timed entry call. If the barrier becomes true while the delay is running, the delay is not aborted. A reason for this strange behavior might be a call to a protected function in the entry_barrier itself. > 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. I have a buffer, filled by a single task and read by an unknown number of tasks. It's a stream multiplier implemented using a ringbuffer structure. The writer task fills a proteced type (ringbuffer) using an protected procedure, while the reader tasks call the protected procedure to get their data. In order to prevent polling, I implemented a second protected type (constrainted with an anonymous access to the ringbuffer) to encapsulate the reader position variable and use it for an entry barrier on this second type. If I had to stick to polling anyway, I can drop the second proteced type and poll the protected ringbuffer directly.