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 16:20:51 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!jfk3-feed1.news.digex.net!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!typhoon.san.rr.com!not-for-mail Message-ID: <3C4618E9.588010F8@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to avoid unreferenced objects (mutexes etc) References: <3c3ee8c8.105408250@News.CIS.DFN.DE> <3c429d1c.2624281@News.CIS.DFN.DE> <3C445F34.44697AEF@san.rr.com> <3C44CFBD.BC1ED52F@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Jan 2002 00:21:42 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1011226902 66.75.151.160 (Wed, 16 Jan 2002 16:21:42 PST) NNTP-Posting-Date: Wed, 16 Jan 2002 16:21:42 PST Organization: Road Runner Xref: archiver1.google.com comp.lang.ada:18991 Date: 2002-01-17T00:21:42+00:00 List-Id: Matthew Heaney wrote: > 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. I must admit that I'm not 100% clear on how this is better than a selective accept, given that a selective accept allows me to time out and to pick whichever entry is available first. I don't think I can pick whichever protected object guard opens first, can I? > Don't use selective accepts in tasks. This is old-fashioned. Rewrite your > tasks to make blocking calls to an internal protected object. Have > operations communicate with the task by calling the protected object, which > wakes up the waiting task. Which is basically what I did. Except there were about 20 or 30 entry points, with various combinations or acceptabilities - i.e., only some operations made sense in some states. There was also a requirement to wait for events from other sources (e.g., events from the UI or events from the I/O framework). So I wound up with protected entries that waited for this or that or the other, then told you which, which you then called.... anyway, it was an awful mess compared to what it could have been had I been able to have multiple task bodies defined for a single task type. But thanks for the advice. If I ever go back to developing this, I'll rethink it again. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The opposite of always is sometimes. The opposite of never is sometimes.