Re: Streams and Concurrency

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <76dgdl$qle$1@nnrp1.dejanews.com> dennison@telepath.com writes:

 > That's the first thing I thought of too. This solution protects the
 > stream itself from corruption just fine. The problem is that it
 > provides absolutely no protection for the *data* in the stream. If
 > I do a 'Write of a record, that gets translated into *several*
 > "Write" calls to the stream, not just one. There's nothing stopping
 > another task from making a call to the stream's Write subprogram in
 > the middle of my record's 'Write. There's nothing stopping the
 > stream service task from calling the stream's Read procedure in the
 > middle of my 'Write either...

    This is wrong.  The encapsulation as illustrated by Jim Rogers
does it right.  The protected object doesn't wrap every call to 'Read
or 'Write, just the highest level calls.  Even if one of those calls
causes many lower level calls all happen inside a single call to the
protected object.

 > Making the stream a proteced object does nothing for me here.
    
    This is trying to solve the wrong problem.  Putting calls to the
protected action inside 'Read or 'Write can't work right.  You have to
have a single protected object which encapsulates the particular
stream.  If you need to read and write different types of values to
the same stream, you either have to derive them all from a single
tagged type, or have several sets of read and write entries to the
protected type, one set for each type of object.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...