Protected types

Protected types

[Adam Beneschan]

I'm trying to learn about protected types.  So far I've read through
sections 9.4, 9.5, and D.3 of the manual.  I have a few questions that
I hope someone is kind enough to answer.


Question I: 9.5.1(4) says "A new protected action is not started on a
protected object while another protected action on the same protected
object is underway, unless both actions are the result of a call on a
protected function."

Consider a case where Ceiling_Locking does not apply.  Task T1 starts
a call on a protected function P.F1 (P is a protected object).  While
P.F1 is still in progress, task T2 tries to call a protected procedure
P.P2.  Clearly the call cannot start.  So T2 has to wait until it can
call the procedure.  Now, while P.F1 is still in progress and task T2
is still waiting, task T3 calls another protected function P.F3.
Which of the following is true?

(1) The call to P.F3 is started immediately, while T2 is still waiting
    to call P.P2.
(2) Task T3 must wait until T1's call to P.F1, and then T2's call to
    P.P2, are completed.
(3) It isn't defined by the language, and either (1) or (2) can
    happen.  Or, it would be defined by an implementation-defined
    Locking_Policy.

Side question: My reading of the manual is that this situation cannot
occur on a single-processor system with Ceiling_Locking; is my
understanding correct?


Question II: 9.5.1(2) says that within the body of a protected
function, the current instance of the enclosing protected unit is
defined to be a constant.  Thus, you can't assign to a component in
the body of a protected function.  9.5(9) says a call on a protected
procedure is defined to be an update of the object; therefore, a
protected function can't make an internal call of a protected
procedure, either.

However, the language allows local procedures to be declared in the
body.  A local procedure is not a protected procedure, since it's not
declared in a protected_definition (9.5.1(1)).  Therefore, it's not
defined to be an update of the object.  Therefore, there doesn't seem
to be any prohibition on a protected function calling a local
procedure.  According to 9.5.1(2), local procedures are allowed to
update components.

So does this mean that a program can get around the restriction on
protected functions not being allowed to update components, simply by
letting the function call a local procedure that updates the
components?  It seems like I must have missed something, but what?


Question III: 9.4(17) says that the entry queue for each entry is
defined to be a component of the protected object.  Since I presume
the LRM is not telling implementors how to implement entry queues, and
since such a component is unnamed and cannot be accessed the way other
components are, what is accomplished by defining it to be a component?
I'm sure that doing so makes the entry queues subject to some other
language rule, but I can't imagine what rule might be involved here,
and I'm curious.

                                -- thanks, Adam


Sent via Deja.com
http://www.deja.com/

Re: Protected types

[Jeffrey Carter]

Adam Beneschan wrote:
> 
> Question I: 9.5.1(4) says "A new protected action is not started on a
> protected object while another protected action on the same protected
> object is underway, unless both actions are the result of a call on a
> protected function."
> 
> Consider a case where Ceiling_Locking does not apply.  Task T1 starts
> a call on a protected function P.F1 (P is a protected object).  While
> P.F1 is still in progress, task T2 tries to call a protected procedure
> P.P2.  Clearly the call cannot start.  So T2 has to wait until it can
> call the procedure.  Now, while P.F1 is still in progress and task T2
> is still waiting, task T3 calls another protected function P.F3.
> Which of the following is true?
> 
> (1) The call to P.F3 is started immediately, while T2 is still waiting
>     to call P.P2.
> (2) Task T3 must wait until T1's call to P.F1, and then T2's call to
>     P.P2, are completed.
> (3) It isn't defined by the language, and either (1) or (2) can
>     happen.  Or, it would be defined by an implementation-defined
>     Locking_Policy.

The ARM allows protected functions to proceed simultaneously, but does
not require it. So the answer is that it's implementation defined.
Another possibility is that T3 waits for T1's call to P.F1 to complete,
then T3's call to P.F3 executes, followed by T2's call to P.P2.

> Side question: My reading of the manual is that this situation cannot
> occur on a single-processor system with Ceiling_Locking; is my
> understanding correct?

This is my understanding also. No task with a priority <= P's ceiling
priority is allowed to run while T1's call to P.F1 is running. No task
with a priority > P's ceiling priority may call any of P's operations.

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail