Re: an error in Re: tasking

[stt@houdini.camb.inmet.com (Tucker Taft)]

Frank Ecke (franke@minet.uni-jena.de) wrote:
: ...
: Very well, but why is a rendezvous not an abort-deferring operation when the
: server is aborted?  Or, to be more precise, why is the rendezvous treated
: differently in the case of aborting a task that executes an accept statement
: and in the case of aborting the triggering entry call in the ATC statement?

:    After all, it is the server that manipulates the global data structures and
: aborting it creates the mess.

The rendezvous model is that a server doesn't manipulate global data
structures.  They manipulate their *own* data structures.
In other words, the server is "global," the data structures are
internal to the server.

So if you abort the server, then there is nothing to protect,
since the data structures are internal to the server.

Aborting this kind of server task is analogous to doing an
unchecked deallocation on an object.  You had better do it
only when you have no further interest in the object.

There are other interesting models, where there are multiple
server tasks, all sharing a common data structure.  In Ada 83,
the only way to do this would have been to have yet another task,
which all the server tasks communicated with, which managed this
shared common data structure.  In Ada 95, this shared common
data structure could be a protected object.

In either model, the actual manipulation of the shared common
data structure by the multiple servers would be abort-deferred,
because it would be implemented by entry (or protected) *calls* 
on the shared common data object/task, not on *accepts.*

In almost any conceivable use of rendezvous, the accept statement
is the time when the acceptor updates its own *internal* data
structures, and communicates with the caller.  It is not the
time when it manipulates some shared global data structure
(unless there is a nested entry/protected call inside the accept statement,
which again would be abort-deferred).

: I hope someone can shed some light on these issues.

See above.

: Frank

: --
: Frank Ecke <franke@minet.uni-jena.de>

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company