Re: LRM question - access types and con

Re: LRM question - access types and con

[stt]

Re: Allocators and tasking.

The programmer need only worry about declared variables which are shared
between tasks.  An access collection is not considered an explicitly
declared variable in this sense.

The implementation must worry about all "hidden" shared data.

Therefore, an implementation must protect its run-time data structures
from simultaneous access.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: LRM question - access types and con

[Jerry Callen]

In article <20600054@inmet> stt@inmet.inmet.com writes:
>The programmer need only worry about declared variables which are shared
>between tasks.  An access collection is not considered an explicitly
>declared variable in this sense.
>The implementation must worry about all "hidden" shared data.
>Therefore, an implementation must protect its run-time data structures
>from simultaneous access.

So what about the built-in I/O packages? Is it safe for multiple tasks
to be issuing, say, Put_Line calls without worrying about synchronization?

[Aside: I think I know what Tucker's response will be; he'll say that the
 I/O packages are just like user packages, they just happen to come with
 the compiler, so they are not required to be "thread-safe."]

I bring this up because it has been a repeated thorn in my side over the
years. I've always felt that, at the very least, the built-in I/O packages
should provide some means of requesting synchronization in the face of
tasking. Maybe a form string parameter?

>S. Tucker Taft
>Intermetrics, Inc.

-- Jerry "RTS hack" Callen
   jcallen@encore.com

Re: LRM question - access types and con

[Michael Feldman]

In article <20600054@inmet> stt@inmet.inmet.com writes:
 >
 >Re: Allocators and tasking.
 >
 >The programmer need only worry about declared variables which are shared
 >between tasks.  An access collection is not considered an explicitly
 >declared variable in this sense.
 >
 >The implementation must worry about all "hidden" shared data.
 >
 >Therefore, an implementation must protect its run-time data structures
 >from simultaneous access.
This comes as very good news. Is there an AI that governs it, or is it
part of the folklore somewhere? Is it tested in the ACVC?

Re: LRM question - access types and con

[Vinod Grover]

In article <1996@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
>                                Is it tested in the ACVC?
It sounds very simple. Why dont you write a test for it?

Re: LRM question - access types and con

[Michael Feldman]

In article <138098@sun.Eng.Sun.COM> grover@brahmand.Eng.Sun.COM (Vinod Grover) writes:
>In article <1996@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
>>                                Is it tested in the ACVC?
>It sounds very simple. Why dont you write a test for it?
Well, I don't think it's a simple as all that. What needs to be tested is
whether the allocator is safe in the presence of a run time system in which
tasks can be arbitrarily interrupted (pre-empted, whatever). Do you have a
good idea for a program that can create these conditions, i.e. that is 
such that we can control the timing precisely enough to guarantee that the
two tasks executing allocator calls will be interrupted precisely in the
middle of their calls?

I am reassured by Tucker Taft's assertion that an implementation has to be
sure its runtime data structures aren't "corrupted" in tasking situations.
I asked about the ACVC because, since I've never seen that assertion in 
writing "officially," I wonder what the authority is for it.

Re: LRM question - access types and con

[Charles H. Sampson]

In article <12142@encore.Encore.COM> jcallen@encore.com (Jerry Callen) writes:
>
>So what about the built-in I/O packages? Is it safe for multiple tasks
>to be issuing, say, Put_Line calls without worrying about synchronization?
>
     My answer is a variant of my followup to the original question:  A pro-
grammer doesn't have to worry about synchronizing calls to the I/O procedures
provided no pair of tasks is operating on the same file; otherwise the imple-
mentation will not satisfy the semantics of the LRM ("Put_line calls the
procedure Put for the given string ...").

     If two tasks are accessing a common file, then all bets are off.  The
file becomes a shared resource and synchronization is definitely the program-
mer's responsibility.  In the case of text I/O, Put_line is defined, ulti-
mately, in terms of repeated calls on Put for single characters.  With this
definition, interlacing of strings is almost guaranteed.

     Should the definition be changed?  It's not easy because there is no
obvious useful way to synchronize the tasks.  Guaranteeing private access
to the file during output of words, sentences, lines, and paragraphs are
all clearly inadequate.  (How often is a report with alternate paragraphs
coming from two different sources useful?)

                              Charlie Sampson