Re: Complexity of protected objects

[dewar@gnat.com (Robert Dewar)]

nickroberts@ukf.net (Nick Roberts) wrote in message news:<3c7e7c60.8192226@news.cis.dfn.de>...
> On Mon, 25 Feb 2002 17:35:45 GMT, Jim Rogers

> It's perhaps a little sweeping to say "I/O is always 
> potentially blocking". There may be certain rare cases 
> where this is not so. But it will certainly
> always be so for reading or writing files, in practice.

Again this is wrong, and is based on the very common misunderstanding
that the technical term "potentially
blocking" corresponds to the OS/notion of the current
task being blocked. It does not!

The point is that *for a very particular kind of implementation
approach*, you will want to make this
correspondence, so in this environment (typically a
low level implementation on a monoprocessor), you will
want to make the correspondence, and the provision in the
RM allows you to do so.

But in more typical environments, e.g. working on top of
an operating system, or real time executive, there is absolutely no
requirement to restrict what can be done
in protected subprograms, and in practice may implementations do not
do so.


> Consider, for example, virtual memory. Depending on the 
> peculiarities of the Ada implementation and the target 
> execution environment, it may be that the execution of a 
> protected subprogram could cause a virtual memory 'page 
> fault' at any point in its execution. Such page faults 
> will typically cause I/O activity to occur (to swap a 
> page in, swap a page out, allocate a page on secondary 
> storage, or whatever). But I/O is 'potentially blocking'.

Now the full scale of the confusion hits. Of *COURSE* it
is the case that a memory read is NOT potentially blocking
in the RM sense, even if in practice in some operating
systems it might cause a context switch.


> Agreed.
> 
> Tony Gair wrote:
> >>(is this an oxymoron?).
> 
> Well, I admire the shapeless solidity of the question.
> 

Now there is a *true* oxymoron, very nice, quite poetic :-)