stt@inmet.inmet.com (06/27/90)
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
jcallen@Encore.COM (Jerry Callen) (06/28/90)
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
mfeldman@seas.gwu.edu (Michael Feldman) (06/29/90)
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?
grover@brahmand.Eng.Sun.COM (Vinod Grover) (06/29/90)
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?
mfeldman@seas.gwu.edu (Michael Feldman) (06/30/90)
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.
sampson@cod.NOSC.MIL (Charles H. Sampson) (06/30/90)
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