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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns13feed!worldnet.att.net!attbi_s72.POSTED!53ab2750!not-for-mail
From: "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org>
Organization: jrcarter at acm dot org
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: protected type interrupts
References: <1156430839.745932.279060@75g2000cwc.googlegroups.com>
In-Reply-To: <1156430839.745932.279060@75g2000cwc.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <lXqHg.151559$1i1.129101@attbi_s72>
NNTP-Posting-Host: 12.201.97.176
X-Complaints-To: abuse@mchsi.com
X-Trace: attbi_s72 1156463441 12.201.97.176 (Thu, 24 Aug 2006 23:50:41 GMT)
NNTP-Posting-Date: Thu, 24 Aug 2006 23:50:41 GMT
Date: Thu, 24 Aug 2006 23:50:41 GMT
Xref: g2news2.google.com comp.lang.ada:6365
Date: 2006-08-24T23:50:41+00:00
List-Id: <comp.lang.ada>

REH wrote:
> I am having a disagreement with a compiler vendor.  I am using a
> protected type for an interrupt handler (see below).  The handler
> simply sets a boolean to true that an entry is using as a guard.  The
> entry is called by a task.  Basically, the task is blocked until
> signaled by the interrupt to do the processing.  With newer versions of
> their compiler, the computer resets.  They say it is because they are
> calling the entry at the interrupt level, and not the task level (we
> process this in a task because we have to do things you cannot do in a
> interrupt).  They say the LRM allows them to do this.  Is that true?  I
> call the entry from a task, but its allow to be executed in the
> interrupt handler.  That does not seem right.

If a call to a procedure or entry of a protected object changes the 
barrier on another entry to True, the thread of control that changed the 
barrier is allowed to execute the newly open entry on behalf of the task 
that called it. So the entry is not being executed in the interrupt 
handler, but by the thread of control that called the interrupt handler.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07