* protected type interrupts
@ 2006-08-24 14:47 REH
2006-08-24 15:39 ` Jean-Pierre Rosen
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: REH @ 2006-08-24 14:47 UTC (permalink / raw)
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.
protected Interrupt_Object is
procedure Isr;
pragma Attach_Handler(Isr, XXX);
pragma Interrupt_Priority(XXX);
entry Process_Interrupt;
private
pragma Suppress(All_Checks, On => Isr);
Triggered : Boolean := False;
end Interrupt_Object;
protected body Interrupt_Object is
procedure Isr is
begin
Triggered := True;
end Isr;
entry Process_Interrupt when Triggered is
begin
Triggered := False;
-- process interrrupt
end Process_Interrupt;
end Interrupt_Object;
task body Interrupt_Task is
begin
loop
Interrupt_Object.Process_Interrupt;
end loop;
end Interrupt_Task;
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 14:47 protected type interrupts REH
@ 2006-08-24 15:39 ` Jean-Pierre Rosen
2006-08-24 16:23 ` REH
2006-08-24 20:11 ` Simon Wright
2006-08-24 23:50 ` Jeffrey R. Carter
2 siblings, 1 reply; 21+ messages in thread
From: Jean-Pierre Rosen @ 2006-08-24 15:39 UTC (permalink / raw)
REH a �crit :
> 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?
C.3.1 (17) allows them to pretty much anything. Apparently, a
ceiling_priority is in effect (either because you specified it, or by
default), thus your task inherits the ceiling of the protected type
(which is an interrupt_priority), and this implementation seems to
forbid an entry to be called at an interrupt level.
A work-around could be:
protected Relay_Object is
procedure Isr;
entry Process_Interrupt;
private
Triggered : Boolean := False;
end Relay_Object;
protected Interrupt_Object is
procedure Isr;
pragma Attach_Handler(Isr, XXX);
pragma Interrupt_Priority(XXX);
private
pragma Suppress(All_Checks, On => Isr);
end Interrupt_Object;
protected body Relay_Object is
procedure Isr is
begin
Triggered := True;
end Isr;
entry Process_Interrupt when Triggered is
begin
Triggered := False;
-- process interrrupt
end Process_Interrupt;
end Relay_Object;
protected body Interrupt_Object is
procedure Isr is
begin
Relay_Object.Isr;
end Isr;
end Interrupt_Object;
This way, the task is not calling a PO that serves as an interrupt
handler, thus C.3.1 (17) does not apply.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 15:39 ` Jean-Pierre Rosen
@ 2006-08-24 16:23 ` REH
2006-08-24 18:15 ` Adam Beneschan
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: REH @ 2006-08-24 16:23 UTC (permalink / raw)
Jean-Pierre Rosen wrote:
> C.3.1 (17) allows them to pretty much anything. Apparently, a
> ceiling_priority is in effect (either because you specified it, or by
> default), thus your task inherits the ceiling of the protected type
> (which is an interrupt_priority), and this implementation seems to
> forbid an entry to be called at an interrupt level.
>
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?
Another work-around suggested to me was to move the processing logic
out of the entry and into the task, and just use the entry for the
triggerring. What do you think about this?
REH
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 16:23 ` REH
@ 2006-08-24 18:15 ` Adam Beneschan
2006-08-24 19:16 ` REH
2006-08-24 23:47 ` Jeffrey R. Carter
2006-08-25 6:38 ` Jean-Pierre Rosen
2 siblings, 1 reply; 21+ messages in thread
From: Adam Beneschan @ 2006-08-24 18:15 UTC (permalink / raw)
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.]
-- Adam
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 18:15 ` Adam Beneschan
@ 2006-08-24 19:16 ` REH
2006-08-24 21:16 ` Adam Beneschan
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: REH @ 2006-08-24 19:16 UTC (permalink / raw)
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?
REH
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 14:47 protected type interrupts REH
2006-08-24 15:39 ` Jean-Pierre Rosen
@ 2006-08-24 20:11 ` Simon Wright
2006-08-24 23:50 ` Jeffrey R. Carter
2 siblings, 0 replies; 21+ messages in thread
From: Simon Wright @ 2006-08-24 20:11 UTC (permalink / raw)
"REH" <spamjunk@stny.rr.com> writes:
> 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.
So why do they support POs as interrupt handlers at all? what do they
expect you to do?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 19:16 ` REH
@ 2006-08-24 21:16 ` Adam Beneschan
2006-08-24 21:39 ` REH
2006-08-25 6:45 ` Jean-Pierre Rosen
2006-08-24 23:55 ` Jeffrey R. Carter
2006-08-25 6:42 ` Jean-Pierre Rosen
2 siblings, 2 replies; 21+ messages in thread
From: Adam Beneschan @ 2006-08-24 21:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 21:16 ` Adam Beneschan
@ 2006-08-24 21:39 ` REH
2006-08-25 6:45 ` Jean-Pierre Rosen
1 sibling, 0 replies; 21+ messages in thread
From: REH @ 2006-08-24 21:39 UTC (permalink / raw)
Adam Beneschan wrote:
> 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
That makes sense. Thanks.
REH
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 16:23 ` REH
2006-08-24 18:15 ` Adam Beneschan
@ 2006-08-24 23:47 ` Jeffrey R. Carter
2006-08-25 6:38 ` Jean-Pierre Rosen
2 siblings, 0 replies; 21+ messages in thread
From: Jeffrey R. Carter @ 2006-08-24 23:47 UTC (permalink / raw)
REH wrote:
>
> Another work-around suggested to me was to move the processing logic
> out of the entry and into the task, and just use the entry for the
> triggerring. What do you think about this?
That is probably a good idea. Your protected object has a ceiling
priority that is an interrupt priority, so the entry body, whether
executed by the calling task or by the thread of control from the
interrupt, is executed at an interrupt priority. It's not a good idea to
do any extensive processing at an interrupt priority. Moving the
processing into the task allows it to be done at a lower priority.
--
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 14:47 protected type interrupts REH
2006-08-24 15:39 ` Jean-Pierre Rosen
2006-08-24 20:11 ` Simon Wright
@ 2006-08-24 23:50 ` Jeffrey R. Carter
2006-08-25 6:48 ` Jean-Pierre Rosen
2 siblings, 1 reply; 21+ messages in thread
From: Jeffrey R. Carter @ 2006-08-24 23:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 19:16 ` REH
2006-08-24 21:16 ` Adam Beneschan
@ 2006-08-24 23:55 ` Jeffrey R. Carter
2006-08-25 6:42 ` Jean-Pierre Rosen
2 siblings, 0 replies; 21+ messages in thread
From: Jeffrey R. Carter @ 2006-08-24 23:55 UTC (permalink / raw)
REH wrote:
>
> 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?
In the terms of the ARM, mutual exclusion is not considered potentially
blocking. Only waiting for data synchronization is potentially blocking.
Since protected actions are supposed to be short and quick, and cannot
perform potentially blocking operations, mutual exclusion cannot delay a
task for very long. On the other hand, waiting for an entry barrier to
become true can take forever.
Many external actions, such as I/O, are also considered potentially
blocking.
--
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 16:23 ` REH
2006-08-24 18:15 ` Adam Beneschan
2006-08-24 23:47 ` Jeffrey R. Carter
@ 2006-08-25 6:38 ` Jean-Pierre Rosen
2 siblings, 0 replies; 21+ messages in thread
From: Jean-Pierre Rosen @ 2006-08-25 6:38 UTC (permalink / raw)
REH a �crit :
> Jean-Pierre Rosen 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?
No, calling a protected *procedure* is not potentially-blocking (unlike
calling a protected *entry*). If your compiler has ceiling_locking by
defauly you may have to adjust the priority, though.
> Another work-around suggested to me was to move the processing logic
> out of the entry and into the task, and just use the entry for the
> triggerring. What do you think about this?
Nothing, since I don't know what was a problem with your original
design. As far as I understand, it's the mere fact of calling an entry
of a protected object that serves as interrupt handler, with a priority
in Interrupt_Priority range. So I don't think that moving the logic
would change anything, as long as you still call the entry;
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 19:16 ` REH
2006-08-24 21:16 ` Adam Beneschan
2006-08-24 23:55 ` Jeffrey R. Carter
@ 2006-08-25 6:42 ` Jean-Pierre Rosen
2 siblings, 0 replies; 21+ messages in thread
From: Jean-Pierre Rosen @ 2006-08-25 6:42 UTC (permalink / raw)
REH a �crit :
> 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?
>
The goal of the "potentially blocking" rule is to prevent *unbounded*
blocking. Short blockings, such as those require to provide mutual
exclusion, are OK, because thay are bounded.
Think of it this way: if it can be implemented on a multi-processor by a
simple spin-lock, it is not potentially blocking. If it requires a
queue, and being awaken depends on some non determinable condition, it
is potentially blocking.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 21:16 ` Adam Beneschan
2006-08-24 21:39 ` REH
@ 2006-08-25 6:45 ` Jean-Pierre Rosen
1 sibling, 0 replies; 21+ messages in thread
From: Jean-Pierre Rosen @ 2006-08-25 6:45 UTC (permalink / raw)
Adam Beneschan a �crit :
> 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.
>
Hmmm... yes, as long as you are running on a mono-processor. But the
rules must take care of multi-processors, too. In that case, there is
some blocking, but it can be implemented by spin-locking, thus avoiding
context switches (see my previous message).
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-24 23:50 ` Jeffrey R. Carter
@ 2006-08-25 6:48 ` Jean-Pierre Rosen
2006-08-25 11:33 ` REH
2006-08-25 20:57 ` Jeffrey R. Carter
0 siblings, 2 replies; 21+ messages in thread
From: Jean-Pierre Rosen @ 2006-08-25 6:48 UTC (permalink / raw)
Jeffrey R. Carter a �crit :
> 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.
>
But since you specified a priority for the PO (and assuming
priority_ceiling), you still execute at interrupt priority. Depending on
the hardware and how priorities are managed, this may delay or hide
actual interrupts.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-25 6:48 ` Jean-Pierre Rosen
@ 2006-08-25 11:33 ` REH
2006-08-25 17:27 ` Jean-Pierre Rosen
2006-08-25 20:57 ` Jeffrey R. Carter
1 sibling, 1 reply; 21+ messages in thread
From: REH @ 2006-08-25 11:33 UTC (permalink / raw)
"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:mf6mce.8k2.ln@hunter.axlog.fr...
> But since you specified a priority for the PO (and assuming
> priority_ceiling), you still execute at interrupt priority. Depending on
> the hardware and how priorities are managed, this may delay or hide actual
> interrupts.
>
Are you saying it may be better not to specify a priority?
REH
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-25 11:33 ` REH
@ 2006-08-25 17:27 ` Jean-Pierre Rosen
0 siblings, 0 replies; 21+ messages in thread
From: Jean-Pierre Rosen @ 2006-08-25 17:27 UTC (permalink / raw)
REH a �crit :
> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
> news:mf6mce.8k2.ln@hunter.axlog.fr...
>> But since you specified a priority for the PO (and assuming
>> priority_ceiling), you still execute at interrupt priority. Depending on
>> the hardware and how priorities are managed, this may delay or hide actual
>> interrupts.
>>
>
> Are you saying it may be better not to specify a priority?
>
Not exactly. If your compiler doesn't use priority_ceiling by default
(and you didn't specify it), then the priority is ignored.
Otherwise, the default priority of a protected object is Priority'Last
(D.3(11)), which will result in ceiling violation if called from a PO
which has a priority in the Interrupt_Priority range. You should then
specify a priority at least as high as the one of the other PO.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-25 6:48 ` Jean-Pierre Rosen
2006-08-25 11:33 ` REH
@ 2006-08-25 20:57 ` Jeffrey R. Carter
2006-08-25 23:17 ` REH
1 sibling, 1 reply; 21+ messages in thread
From: Jeffrey R. Carter @ 2006-08-25 20:57 UTC (permalink / raw)
Jean-Pierre Rosen wrote:
>>
> But since you specified a priority for the PO (and assuming
> priority_ceiling), you still execute at interrupt priority. Depending on
> the hardware and how priorities are managed, this may delay or hide
> actual interrupts.
Right. I said that in another message, IIRC. The message you were
replying to was mostly nit picking, correcting the OP's assumption that
the entry was being executed BY the interrupt handler.
--
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-25 20:57 ` Jeffrey R. Carter
@ 2006-08-25 23:17 ` REH
2006-08-26 6:38 ` Jeffrey R. Carter
0 siblings, 1 reply; 21+ messages in thread
From: REH @ 2006-08-25 23:17 UTC (permalink / raw)
"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:bvJHg.152959$1i1.59895@attbi_s72...
>
> Right. I said that in another message, IIRC. The message you were replying
> to was mostly nit picking, correcting the OP's assumption that the entry
> was being executed BY the interrupt handler.
>
It's not my assumption. It IS being executing by the handler, and the
compiler vender says the LRM allows them to do so. References to LRM given
here show they are correct. My assumption (that was proven incorrect) was
that it should been executed by the task that called it. The standard
states that this cannot be relied upon (which explains why you cannot call
"current_task" from an entry).
REH
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-25 23:17 ` REH
@ 2006-08-26 6:38 ` Jeffrey R. Carter
2006-08-26 13:16 ` REH
0 siblings, 1 reply; 21+ messages in thread
From: Jeffrey R. Carter @ 2006-08-26 6:38 UTC (permalink / raw)
REH wrote:
>>
> It's not my assumption. It IS being executing by the handler, and the
> compiler vender says the LRM allows them to do so. References to LRM given
> here show they are correct. My assumption (that was proven incorrect) was
> that it should been executed by the task that called it. The standard
> states that this cannot be relied upon (which explains why you cannot call
> "current_task" from an entry).
No. It may be executed by the same thread of control that executed the
interrupt handler, but that is not the same thing as executing it from
the protected procedure that is the interrupt handler. The ARM does not
allow the latter.
--
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: protected type interrupts
2006-08-26 6:38 ` Jeffrey R. Carter
@ 2006-08-26 13:16 ` REH
0 siblings, 0 replies; 21+ messages in thread
From: REH @ 2006-08-26 13:16 UTC (permalink / raw)
"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:00SHg.153600$1i1.101654@attbi_s72...
> No. It may be executed by the same thread of control that executed the
> interrupt handler,
This is what I was trying to say.
>but that is not the same thing as executing it from the protected procedure
>that is the interrupt handler.
I didn't mean to say this.
Thanks,
REH
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2006-08-26 13:16 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-08-24 14:47 protected type interrupts REH
2006-08-24 15:39 ` Jean-Pierre Rosen
2006-08-24 16:23 ` REH
2006-08-24 18:15 ` Adam Beneschan
2006-08-24 19:16 ` REH
2006-08-24 21:16 ` Adam Beneschan
2006-08-24 21:39 ` REH
2006-08-25 6:45 ` Jean-Pierre Rosen
2006-08-24 23:55 ` Jeffrey R. Carter
2006-08-25 6:42 ` Jean-Pierre Rosen
2006-08-24 23:47 ` Jeffrey R. Carter
2006-08-25 6:38 ` Jean-Pierre Rosen
2006-08-24 20:11 ` Simon Wright
2006-08-24 23:50 ` Jeffrey R. Carter
2006-08-25 6:48 ` Jean-Pierre Rosen
2006-08-25 11:33 ` REH
2006-08-25 17:27 ` Jean-Pierre Rosen
2006-08-25 20:57 ` Jeffrey R. Carter
2006-08-25 23:17 ` REH
2006-08-26 6:38 ` Jeffrey R. Carter
2006-08-26 13:16 ` REH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox