* Re: LRM question - access types and con [not found] <1394@software.software.org> @ 1990-06-27 15:53 ` stt 1990-06-28 13:34 ` Jerry Callen 1990-06-29 3:51 ` Michael Feldman 0 siblings, 2 replies; 6+ messages in thread From: stt @ 1990-06-27 15:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LRM question - access types and con 1990-06-27 15:53 ` LRM question - access types and con stt @ 1990-06-28 13:34 ` Jerry Callen 1990-06-29 21:55 ` Charles H. Sampson 1990-06-29 3:51 ` Michael Feldman 1 sibling, 1 reply; 6+ messages in thread From: Jerry Callen @ 1990-06-28 13:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LRM question - access types and con 1990-06-28 13:34 ` Jerry Callen @ 1990-06-29 21:55 ` Charles H. Sampson 0 siblings, 0 replies; 6+ messages in thread From: Charles H. Sampson @ 1990-06-29 21:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LRM question - access types and con 1990-06-27 15:53 ` LRM question - access types and con stt 1990-06-28 13:34 ` Jerry Callen @ 1990-06-29 3:51 ` Michael Feldman 1990-06-29 13:25 ` Vinod Grover 1 sibling, 1 reply; 6+ messages in thread From: Michael Feldman @ 1990-06-29 3:51 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LRM question - access types and con 1990-06-29 3:51 ` Michael Feldman @ 1990-06-29 13:25 ` Vinod Grover 1990-06-29 17:30 ` Michael Feldman 0 siblings, 1 reply; 6+ messages in thread From: Vinod Grover @ 1990-06-29 13:25 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LRM question - access types and con 1990-06-29 13:25 ` Vinod Grover @ 1990-06-29 17:30 ` Michael Feldman 0 siblings, 0 replies; 6+ messages in thread From: Michael Feldman @ 1990-06-29 17:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1990-06-29 21:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1394@software.software.org> 1990-06-27 15:53 ` LRM question - access types and con stt 1990-06-28 13:34 ` Jerry Callen 1990-06-29 21:55 ` Charles H. Sampson 1990-06-29 3:51 ` Michael Feldman 1990-06-29 13:25 ` Vinod Grover 1990-06-29 17:30 ` Michael Feldman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox