Re: Complexity of protected objects

[dewar@gnat.com (Robert Dewar)]

Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3C7FBD74.D434411E@boeing.com>...


> Certain language-defined subprograms are potentially blocking. In
> particular, the subprograms of the language-defined input-output
> packages that manipulate files (implicitly or explicitly) are
> potentially blocking.
> 
> Thus, I/O as always potentially blocking because the 
> language defines it as such.

Umm, I am afraid our syllogistic apparatus is malfunctioning here. The
predicate said (I will
shout to make sure no one else misses it) LANGUAGE-DEFINED
input-output packages.

It is entirely wrong to assume this says something about
all I/O. The point is that if the implementation introduces
non-language defined I/O, then it will have to decide whether it is PB
or not (in GNAT such I/O is not defined
to be PB).

Even if you do language defined I/O that *is* PB, let's read the RM to
see what happens if you do a PB action in
a PT:

8   During a protected action, it is a bounded error to invoke an
operation that is potentially blocking.  The following are defined to
be potentially blocking operations:

17   If the bounded error is detected, Program_Error is raised.  If
not detected, the bounded error might result in deadlock or a (nested)
protected action on the same target object.

Now of course this means that any program doing PB operations in a PT
has an implementation dependent
effect, so most certainly you need to check that it
will work on the implementation you are using, and
the code is non-portable (since it might not work
on lock-free implementations for instance).