Re: Complexity of protected objects

[nickroberts@ukf.net (Nick Roberts)]

On Mon, 25 Feb 2002 17:35:45 GMT, Jim Rogers
<jimmaureenrogers@worldnet.att.net> strongly typed:

>Using a protected object to read and write files is a clear
>violation of the intention and recommendations for proctected
>objects. Protected objects should be non-blocking. I/O is
>always potentially blocking.

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.

>You even have some potential blocking issues when storing an
>AVL tree. If you dynamically allocate your AVL tree nodes you
>have the possibility of running out of memory. This will either
>result in a blocking situation, or a potential loss of data
>in the AVL tree.

I would suggest this is being ultra-cautious. In practice, dynamic memory
allocation tends to be considered an 'honourary' non-blocking operation
(even though this does actually fly in the face of the reality). It is
certainly better to avoid any dynamic allocation in a protected subprogram
if you easily can.

Remember, you need to consider the practical consequences of a protected
subprogram being blocked; the RM95 can only say what behaviour is or isn't
guaranteed by all conforming Ada 95 implementations.

In the case of running out of memory (for dynamic allocation), you may
consider this to be a rare event, and a show-stopper anyway, and so not
worth worrying about (in terms of how badly it may obstruct other tasks). I
hasten to add that in some applications this attitude would be reckless.

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'.
Disaster! Well no, not really; as long as the 'block' does not last too
long. Similar comments apply to pre-emptive scheduling environments and so
on.

>I would be inclined to use a simple protected buffer object to
>communicate with one or more tasks for the reading and writing,
>and another task to store the AVL tree. Protected operations allow
>you to design a degree of asynchronisity into your system. They are
>not expected to replace tasks for all uses.

Agreed.

Tony Gair wrote:
>>(is this an oxymoron?).

Well, I admire the shapeless solidity of the question.

;-)

-- 
Nick Roberts