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-31 00:51:12 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-meneldur.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Combining entry_call, accept_statment and terminate_statment Date: Wed, 31 Mar 2004 11:03:19 +0200 Message-ID: <4ttk60parnsdj19c34pi38p94uc2rnkj4h@4ax.com> References: <106h7clrs4iio8c@corp.supernews.com> <106jkmlj2g6ik57@corp.supernews.com> NNTP-Posting-Host: tar-meneldur.cbb-automation.de (212.79.194.119) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1080723071 84969447 I 212.79.194.119 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:6685 Date: 2004-03-31T11:03:19+02:00 List-Id: On Tue, 30 Mar 2004 22:47:27 +0000 (UTC), Lutz Donnerhacke wrote: >* Randy Brukardt wrote: >> "Lutz Donnerhacke" wrote in message >>> 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. >> >> Barriers of a PO are re-evaluated whenever a protected action ends, and when >> an entry is called. A barrier which can change state without a protected >> action ending is incorrect and may not work properly. > >So cascading of protected types will not work. They should, AFAIK. >My incorrect version was: > > protected type Ringbuffer is > procedure Put(data : in String); > procedure Get(data : out Buffer; last : out Extended_Buffer_Offset; > missed : out Absolute_Position; pos : in out Absolute_Position); > function Is_New(pos : Absolute_Position) return Boolean; > private > buf : Buffer; > start, stop : Absolute_Position := Absolute_Position'First; > end Ringbuffer; > > protected type Read_Context(ringbuf : access Ringbuffer) is > entry Get(data : out Buffer; last : out Extended_Buffer_Offset; > missed : out Absolute_Position); > private > pos : Absolute_Position := Absolute_Position'First; > end Read_Context; > > protected body Read_Context is > entry Get( > data : out Buffer; last : out Extended_Buffer_Offset; > missed : out Absolute_Position > ) when ringbuf.Is_New(pos) is > begin > ringbuf.Get(data, last, missed, pos); > end Get; > end Read_Context; Ringbuffer.Get(...); in Read_Context is an external call, so it should start a new protected action, which would lead to re-evaluating the barriers of ringbuf.all. So Read_Context.Get would result in re-evaluation of the barriers of both objects. However, I cannot say if ringbuf.Is_New will be called during a re-evaluation of the barriers of Read_Context. But surely it won't, if ringbuff is touched from outside. [ tagged protected object could be very useful in cases like this. Mix-in works poorly here. ] -- Regards, Dmitry Kazakov www.dmitry-kazakov.de