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,6009c73a58f787a0
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-01-16 15:13:45 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Matthew Heaney" <mheaney@on2.com>
Newsgroups: comp.lang.ada
Subject: Re: How to avoid unreferenced objects (mutexes etc)
Date: Wed, 16 Jan 2002 18:18:25 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <u4c298nq0bqs1c@corp.supernews.com>
References: <3c3ee8c8.105408250@News.CIS.DFN.DE>
 <a1o2h1$sfe3f$5@ID-25716.news.dfncis.de> <3c429d1c.2624281@News.CIS.DFN.DE>
 <u48j5j2gh9lse8@corp.supernews.com> <3C445F34.44697AEF@san.rr.com>
 <u48ujffufrl77b@corp.supernews.com> <3C44CFBD.BC1ED52F@san.rr.com>
 <u3d16tfry.fsf@gsfc.nasa.gov> <3C45C12D.A229F569@san.rr.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Complaints-To: newsabuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:18989
Date: 2002-01-16T18:18:25-05:00
List-Id: <comp.lang.ada>


"Darren New" <dnew@san.rr.com> wrote in message
news:3C45C12D.A229F569@san.rr.com...
> Errr, no. I'm pretty sure a selective accept works in tasks.

Yes, it does, but you shouldn't bother using it.  Have the task wait on a
guarded entry of a protected object, and communicate with the task by
calling a protected procedure of the protected object.


> Yes. But the problem is in the callee you want a selective accept, and
> in the caller you want a conditional entry, and you don't want those two
> tied together at compile time.

Fine.  So don't tie them together at compile time.  The task calls a
dispatching operation, and that dispatching operation is implemented in a
derived type by calling a guarded entry of a protected object.

The callee doesn't call an entry directly.  He calls a primitive operation
that is implemented by calling an entry (of a protected object).  I showed
this in my last post.


> In that case, you're screwed. If you
> could derive a task type from another task type, I'd be fine; that is,
> if I could have multiple different task bodies for the same task type,
> I'd not have had even conceptual problems.

The behavior that varies is encapsulated by calling private primitive
operations that dispatch:

package P is

   type T is abstract tagged limited private;

   procedure Op (O : in out T) is abstract;

private

   task type T_Task_Type (O : access T'Class);  --type is class-wide

   type T is abstract tagged limited record
      T_Task : T_Task_Type (T'Access);
   end record;

   procedure Wait (O : access T);  --primitive
end P;

package body P is

   procedure Wait (O : access T) is
   begin
      null;
      pragma Assert (False); --must override
   end;

   type T_Task_Type is
   begin
      loop
         Wait (O);  -- dispatches according to tag of discriminant
         ...
      end loop;
   end T_Task_Type;

end P;

Now you can implement a derived type by extending T with a protected object,
and then overidding Wait so that it calls an entry of the protected object.


> In other words, I reimplemented Ada's entry queues.

I don't think this is necessary.  Find a way to turn tasks into callers of
protected entries, so you can get rid of the select-accept statements.