Version 1.2 of ais/ai-00045.txt

Unformatted version of ais/ai-00045.txt version 1.2
Other versions for file ais/ai-00045.txt

!standard 09.05.03 (00)          99-07-08 AI95-00045/03
!class confirmation 95-06-25
!status WG9 approved 96-12-07
!status ARG Approved 10-0-0 96-10-07
!status work item 95-06-25
!status received 95-06-25
!priority Low
!difficulty Easy
!subject Servicing of entry calls is part of a protected action
!summary
For an entry of a protected object, enqueueing and dequeueing an entry call always take place as part of a protected action. Hence, if a barrier depends on the entry's Count attribute, any change in the value of the Count will necessarily cause the reevaluation of the barrier.
!question
Does the following example (given in the Ada 95 Rationale January 1995) suffer from a deadlock? (No.)
protected Event is entry Wait; entry Signal; end Event;
protected body Event is entry Wait when Signal'Count > 0 is begin
null; end Wait;
entry Signal when Wait'Count = 0 is begin
null; end signal; end Event;
Assume that a call for Wait comes first, the entry is closed and the entry call is added to an entry queue. Now assume that a call for entry Signal comes, the entry is closed and this call is queued on Signal's queue.
!response
The call on Signal starts a new protected action, by 9.5.3(8). This causes servicing of the entry queues, by 9.5.3(15). This servicing will notice that the barrier of Wait is now True. Thus, no deadlock occurs.
!ACATS test
Create a C-test like the question; a correct implementation would not deadlock.
!appendix

!section 9.5.3(00)
!subject Entry calls
!reference AARM-  9.5.3
!reference as: 95-5131.a Tzilla Elrad  95-4-28>>
!discussion
Does  the following  example (given at the Ada 95 Rationale January
1995) suffer from a deadlock?

Protected Event is
     entry wait;
     entry signal;
end Event;

Protected body Event is
     entry Wait when Signal'count>0 is
     begin
     null;
     end Wait;

     Entry Signal when Wait'count=0 is
     begin
     null
     end signal;
end Event;

According to 9.5.3 Entry Calls (13) : " An entry with queued
calls can be serviced under the following circumstances:
* ..............
* If after performing, as part of a protected action on the
associated protected object, an operation on the object  other
than a call on a protected function, the entry is checked and
found to be open."
Assume that a call for Wait is coming first, the entry is closed
and the entry call is added to an entry queue.    Now assume that
a call for entry Signal comes,  The entry is closed and this call is
queued on Signal's queue.   NO  entry body is preformed,
therefore, no check on a potential open entry might be
preformed.    My point is:  since it takes a performance of an
entry/procedure body to re-evaluate barriers on a queued entries
and in our example this might NEVER be preformed (the fact
that an entry body is null does matter  here).  Would this
program deadlock?
 -Tzilla Elrad

****************************************************************

!section 9.5.3(13)
!section 9.5.3(18)
!subject Entry calls
!reference RM95-9.5.3(13)
!reference RM95-9.5.3(18)
!reference 95-5131.a Tzilla Elrad  95-4-28
!from Anthony Gargaro 95-04-29
!reference as: 95-5132.a Anthony Gargaro  95-4-29>>
!discussion

> Does  the following  example (given at the Ada 95 Rationale January
> 1995) suffer from a deadlock?

It seems that deadlock is precluded by the wording of 9.5.3(18) that requires
the servicing of entry queues until there are no open entries prior to
completing the protected action.


****************************************************************

!section 9.5.3(00)
!subject Entry calls
!reference AARM-  9.5.3
!reference 95-5131.a Tzilla Elrad  95-4-28
!reference as: 95-5133.a Ted Baker  95-4-29>>
!discussion

| Does  the following  example (given at the Ada 95 Rationale January
| 1995) suffer from a deadlock?

| Protected Event is
|      entry wait;
|      entry signal;
| end Event;

| Protected body Event is
|      entry Wait when Signal'count>0 is
|      begin
|      null;
|      end Wait;
|      Entry Signal when Wait'count=0 is
|      begin
|      null
|      end signal;
| end Event;

| According to 9.5.3 Entry Calls (13) : "An entry with queued
| calls can be serviced under the following circumstances:
| * ..............
| * If after performing, as part of a protected action on the
| associated protected object, an operation on the object  other
| than a call on a protected function, the entry is checked and
| found to be open."
| Assume that a call for Wait is coming first, the entry is closed
| and the entry call is added to an entry queue.    Now assume that
| a call for entry Signal comes,  The entry is closed and this call is
| queued on Signal's queue.   NO  entry body is preformed,
| therefore, no check on a potential open entry might be
| preformed.    My point is:  since it takes a performance of an
| entry/procedure body to re-evaluate barriers on a queued entries
| and in our example this might NEVER be preformed (the fact
| that an entry body is null does matter  here).  Would this
| program deadlock?

The enqueue and dequeue operations on protected entries are
themselves protected actions, since they take place under the
protection of the protected object.  Thus, when your call to
Signal has been queued, the barriers are re-evaluated, and the
barrier for Wait is found to be open.



****************************************************************

Questions? Ask the ACAA Technical Agent