Re: Combining entry_call, accept_statment and terminate_statment

[Lutz Donnerhacke <lutz@iks-jena.de>]

* 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.

> 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.

> 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.

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.