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.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 103376,ba19b629e3223dba
X-Google-Attributes: gid103376,public
From: Wilhelm.Spickermann@t-online.de (Wilhelm Spickermann)
Subject: Re: Q: Protected types and entries (long)
Date: 1999/02/16
Message-ID: <36C9C47D.F3461845@t-online.de>#1/1
X-Deja-AN: 445035207
Content-Transfer-Encoding: 8bit
References: <36C98180.98296205@siemens.at>
X-Accept-Language: de,en
X-Sender: 0211750756-0001@t-online.de
Content-Type: text/plain; charset=iso-8859-1
X-Complaints-To: abuse@t-online.de
X-Trace: news00.btx.dtag.de 919192701 1619 0211750756-0001 990216 19:18:21
Organization: Spickermann, Duesseldorf, Germany
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-02-16T00:00:00+00:00
List-Id: <comp.lang.ada>

Erik Margraf wrote:
> 
> Recently I started to learn about protected types. I tried to do
> something like the following:
> 
> (Not 100% Ada :-)
> 
> ...
>    type buffer is array (...) of character;
>    protected type Object is
>      entry put (data : in buffer);
>    private
>      internal_buffer : array (BIG_Enough) of character;
>      items_in_buffer : integer := 0;
>    end;
> ...
>    protected Object body
> 
>    entry put (data : in buffer)
>         when data'size + items_in_buffer <= internal_buffer�size is
>    begin
>     ...
>    end;
>    end Object;
> 
> Since the reference to a formal parameter of an entry is not allowed,
> gnat
> refused to compile this ;-). I changed the code to
> 
>    type buffer is array (...) of character;
>    protected type Object is
>      entry put (data : in buffer);
>    private
>      entry p_put (data : in buffer);
>      internal_buffer : array (BIG_Enough) of character;
>      data_size : integer;
>      items_in_buffer : integer := 0;
>    end;
> ...
>    protected Object body
>    entry put (data : in buffer)
>         when true is
>    begin
>       data_size := data�size;
>       if data_size + items_in_buffer > internal_buffer�size then
>         requeue p_put;
>       end if;
>    end;
> 
>    entry p_put (data : in buffer)
>         when data_size + items_in_buffer <= internal_buffer�size is
>    begin
>     ...
>    end;
>    end Object;
> 
> This compiles.
> Now my questions:
> 
>         - Can someone tell me WHY this limitation in the barrier exists?
>         - Is my "solution" really a solution to this problem?
>         - (What) Should I do something different?
> Thanks
> 
> Erik Margraf
> 
> --
> --------------------------------------------------------------------
> -- Erik Margraf
> -- Siemens Austria PSE KB2
> -- erik.margraf@siemens.at
> -- +43 1 1707 45887
> --------------------------------------------------------------------
I think the second solution will not work. Think of several tasks
waiting
for the barrier of p_put to become open. Then one task with a small
data'size enters put: It will change data_size and open the barrier for
all of them...
(The barrier does not belong to a call -- it belongs to the entry!)

The solution to your problem is decribed in Burns, Wellings: Concurrency 
in Ada (8.1.2).

The reason for the limitations on barriers is the high efficiency of 
implementation which was achieved by it. Protected objects are even more
efficient than semaphores, because one thread of control can execute the
protected operation of another and continue to work without any context
switch. 

Example: We have a one element buffer which is initially empty, a task R
         which is reading elements all day long and task W which is
writing
         all day:
 - task R tries to read and gets blocked
 - task W writes
 - task W executes the protected read of R and makes R executable
 - task W writes
 - task W tries to write the third element and gets blocked
 (cf. Ada 95 Rationale: 9.1.3)

Wilhelm Spickermann