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,8eff44ec1bcf8433
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-10-21 23:46:26 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newspeer.monmouth.com!news.monmouth.com!shell.monmouth.com!not-for-mail
From: ka@sorry.no.email (Kenneth Almquist)
Newsgroups: comp.lang.ada
Subject: Re: Container reqs
Date: 22 Oct 2001 02:46:17 -0400
Organization: A poorly-installed InterNetNews site
Message-ID: <9r0fbp$l5t$1@shell.monmouth.com>
References: <9qctpn$lil$1@news.huji.ac.il>
 <slrn9slt9m.i2.lutz@taranis.iks-jena.de> <3BCC01B1.18C18C98@free.fr>
 <3BCC6CB7.20BAA30D@boeing.com>
NNTP-Posting-Host: shell.monmouth.com
Xref: archiver1.google.com comp.lang.ada:15011
Date: 2001-10-22T02:46:17-04:00
List-Id: <comp.lang.ada>

Jeffrey Carter <jeffrey.carter@boeing.com> wrote:
> Jean-Marc Bourguet wrote:
>> 
>> I'm not for making a container "threadsafe"  to the point where
>> several tasks may modify the container without providing their
>> synchronisation.
>> In my experience
>>    * most containers are accessed only by one task
>>    * for those who are not, an explicit synchronisation is needed for
>>      other purpose as the container is not the only part member of the
>>      datastructure which has to be modified atomically.
>
> This is an interesting assertion, considering that a protected queue is
> a useful and common form of intertask communication.

When using a queue for interprocess communication, you normally want a
reader task to block when the queue is empty.  You probably want the
writer to block when the queue is full, though it is easier to imagine
exceptions to this.  The natural way to accomplish this in Ada is to
wrap the queue in a protected type with appropriate entry barriers, as
is shown in the code at the end of this posting.  If you do this, the
semantics for protected types mean that the queue will never be
accessed by two tasks simultaneously, so there is no need for the
queue type to be "threadsafe."

I'm not saying that intertask communication mechanisms should not be
part of the library.  I just don't think that "threadsafe" containers
are a particularly useful intertask communication mechanism.
				Kenneth Almquist


generic
   type Element is private;
package Channel is

   package Element_Queue is new Queue(Element);

   protected type T is
      entry Put(Item : Element);
      entry Get(Item : out Element);
   private
      Q : Element_Queue.T;
   end T;

end Channel;


package body Channel is
   protected body T is

      entry Put(Item : Element) when not Element_Queue.Is_Full(Q) is
      begin
         Element_Queue.Insert(Q, Item);
      end Put;

      entry Get(Item : out Element) when not Element_Queue.Is_Empty(Q) is
      begin
         Element_Queue.Remove(Q, Item);
      end Get;

   end T;
end Channel;