!standard 9.05.01 (8) 01-05-31 AC95-00008/01 !class uninteresting 01-05-31 !status received 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. ****************************************************************