Version 1.2 of acs/ac-00008.txt

Unformatted version of acs/ac-00008.txt version 1.2
Other versions for file acs/ac-00008.txt

!standard 9.05.01 (8)          01-05-31 AC95-00008/01
!class confirmation 01-05-31
!status received no action 01-05-17
!subject Blocking calls in protected object subprograms
!summary
!appendix

!topic Blocking calls in protected object subprograms
!reference RM95-9.5.1(8)
!from Michael Gray
!sent Thursday, May 17, 2001, 7:23 AM
!discussion

The LRM (section 9.5.1 para. 8) states that:- during a protected action it
is a bounded error to invoke an operation that is potentially blocking. It
then states (in para. 17) that:  if the bounded error is detected,
Program_Error is raised and if not detected it might result in deadlock or a
(nested) protected action on the same target object.

The question is, what is the interpretation of "detected"? Arguably, an
implementation is under no obligation to detect the bounded error, and there
are good reasons why implementations should not be under such an obligation
in the general case (i.e. a protected action makes sub-program calls which
in several levels of indirection then invokes a potentially blocking
operation). However, in the most obvious case e.g. directly calling a
potentially blocking operation on the same object within the protected
action, if an implementation converts that direct call into an invocation of
the potentially blocking operation, then de facto the call of the
potentially blocking operation has been "detected" and it could be argued
that the implementation is bound by the LRM to raise Program_Error.

In the absence of any clarification, all a user can read into these LRM
words is "invoking an operation that is potentially blocking may result in a
Program_Error or it may result in deadlock or a (nested) protected action on
the same target object". The words about "detection" are not useful. So a
clarification here would be helpful.

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

From: Robert Dewar
Sent: Wednesday, May 23, 2001 5:20 PM

I see no real language issue here, detected means detected. For all practical
purposes, the only test of whether the situation is detected is that a
program error is raised.

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

From: Michael Yoder
Sent: Thursday, May 24, 2001 12:37 PM

I agree with Robert that "detected" can't reasonably mean more than
"happens to be detected by the implementation."  Perhaps it would be
desirable, though, to explicitly say that which of the legal behaviors
occur is "unspecified" as per 1.1.3(18).  This seems clearly intended, but
I don't know if the conclusion can be forced by exegesis.  :-)

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

From: Randy Brukardt
Sent: Friday, May 25, 2001 9:43 PM

> In the absence of any clarification, all a user can read into these LRM
> words is "invoking an operation that is potentially blocking may result in a
> Program_Error or it may result in deadlock or a (nested) protected action on
> the same target object". The words about "detection" are not useful. So a
> clarification here would be helpful.

I think that this description is precisely what was intended by the RM.
Bounded errors have a list of possible results when they are detected and
when they are not detected. There is no requirement in the RM that such
errors are detected (see 1.1.5(8)); if there was, it wouldn't be a bounded
error but rather a dynamic semantics check.

This is in contrast to the totally unspecified erroneous execution, in which
the program can do anything: deadlock, crash, erase your hard disk, cause
you computer to explode, or cause your wife to divorce you. Ada 95 tries to
avoid this as much as possible.

Robert's remark that the only way to tell if the error is detected is that
Program_Error is raised seems right. Some implementations might always
detect the error with a runtime check (Janus/Ada does this to avoid
deadlock); other implementation may prefer to avoid the overhead of the
check. The language allows either implementation.

I'm a little concerned that we're not being responsive to your question. The
problem is, there doesn't seem to be any reason for the question. The RM
seems clear enough; what's missing is any reason why the answer to your
question might matter. The RM seems clear that depending on the
Program_Error to be raised is wrong, and it doesn't seem useful in a real
program.

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


Questions? Ask the ACAA Technical Agent