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-Thread: 103376,e6066104d6deadff X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!m79g2000cwm.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: protected type interrupts Date: 24 Aug 2006 14:16:11 -0700 Organization: http://groups.google.com Message-ID: <1156454170.983452.318450@m79g2000cwm.googlegroups.com> References: <1156430839.745932.279060@75g2000cwc.googlegroups.com> <1156436616.384632.192250@h48g2000cwc.googlegroups.com> <1156443355.219906.237190@h48g2000cwc.googlegroups.com> <1156446985.794916.61470@74g2000cwt.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1156454176 24529 127.0.0.1 (24 Aug 2006 21:16:16 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 24 Aug 2006 21:16:16 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: m79g2000cwm.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news2.google.com comp.lang.ada:6359 Date: 2006-08-24T14:16:11-07:00 List-Id: REH wrote: > Adam Beneschan wrote: > > REH wrote: > > > > > Thanks for the reference. Is your work-around valid? Isn't calling > > > Relay_Object.Isr a potentially blocking operation, and thus a bad thing > > > to do in an interrupt? > > > > I don't think it's potentially blocking... Relay_Object.Isr is a > > procedure, and as I read 9.5.1, a call to a protected *procedure* is > > not a potentially blocking operation unless it's done from the same > > protected object. A call on a protected *entry* would be potentially > > blocking. [This is from the Ada 95 manual. If this has changed in Ada > > 0Y, I can't tell because www.adaic.com isn't responding.] > > > > I don't understand. How can a procedure within a protected object > modify data internal to the object in a thread-safe way without the > potentially blocking effect of enforcing mutual exclusion? If one task > is "using" the object, and another calls one of the object's > procedures, would the second task not be blocked until the first one > exits the object? I'm just reading what the RM says. But, although I'm not an expert at this, I don't believe your argument makes sense given the way protected objects are supposed to work. A task cannot, of course, access data internal to a protected object directly; it has to call one of the PO's subprograms or entries to get it. When it does so, then assuming Ceiling_Locking is in effect, no other task can use the PO---but it's not because other tasks are blocked, it's simply because the protected action runs at a higher priority than any task that could use the PO (and the protected action is supposed to complete very quickly). So no mutual exclusion or blocking is necessary when calling protected subprograms. At least I think that's how it works. -- Adam