Re: Combining entry_call, accept_statment and terminate_statment

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Wed, 31 Mar 2004 09:14:12 +0000 (UTC), Lutz Donnerhacke
<lutz@iks-jena.de> wrote:

>* Dmitry A Kazakov wrote:
>> On Tue, 30 Mar 2004 22:47:27 +0000 (UTC), Lutz Donnerhacke
>>>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.
>
>There are no barriers on Ringbuffer. The only barrier is on Read_Context.
>And the barrier is neither reevaluated on a call to Ringbuffer.Put nor polled.

Of course, because Read_Context's barriers are re-evaluated on the
events related to the Read_Context, which is unreated to Ringbuffer.
Mix-in is not inheritance.

>> So Read_Context.Get would result in re-evaluation of the barriers of both
>> objects.
>
>Read_Context.Get is never called after the first evaluation of the barrier.
>The barrier is never reevaluated. So the system blocked forever.

It could, if you made a proxy in Read_Context for Put of Ringbuffer
and would use it instead.

>> However, I cannot say if ringbuf.Is_New will be called during a
>> re-evaluation of the barriers of Read_Context.
>
>It will, but there is no reevaluated at all.
>
>> But surely it won't, if ringbuff is touched from outside.
>
>Ack.
>
>> [ tagged protected object could be very useful in cases like this.
>> Mix-in works poorly here. ]
>
>Tagging doesn't provide anything useful in this context.
>Please do not mix orthogonal concepts.

It looks like Read_Context extending Ringbuffer or at least using the
events (a protected action end) of the Ringbuffer for its barriers.
The only possible way to do it without surprises is to inherit from
Ringbuffer.

>Entry families does provide the required behavior:
>  An entry family call has two formal argument lists.
>  The first one is evaluated before the barrier and therefor usable in the
>  barrier itself. (That's the real issue on entry families.)
>  The second one is evaluated after the barrier is evaluated to True.

If you want to use actual parameters in barriers, there is another way
- the requeue statement. But I do not see how it might help if a
barrier depends on some external event, as in your example.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de