fouts@lemming. (Marty Fouts) (11/03/88)
I offer, only half humorously, TSO running under OS/360, as the first example of "multiple THREADS of control executing within a single address space" Consider that TSO ran as a partition and invoked its own round robin scheduler to schedule its quantum among its various terminal users, all of which were (sort of) within the same address space. If TSO doesn't qualify, IBM implementations of APL workspaces might. . . Only halfjesting. . . Marty -- +-+-+-+ I don't know who I am, why should you? +-+-+-+ | fouts@lemming.nas.nasa.gov | | ...!ames!orville!fouts | | Never attribute to malice what can be | +-+-+-+ explained by incompetence. +-+-+-+
pardo@june.cs.washington.edu (David Keppel) (11/04/88)
fouts@lemming. (Marty Fouts) writes: >[ earliest threads in 1 address space: TSO (half :-) ] I suspect that the *earliest* is whatever machine had multiple (concurrent) processes. The single address space would be physical addresses, there would have been no protection, ... Does anybody know when the first multiprocessing systems came online at research institutions? How long before they became commercially available? Does this digression have anything to with comp.os.*research*? Nope. ;-D on ( (Re)search me ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
perry@apollo.COM (Jim Perry) (11/05/88)
In article <5338@saturn.ucsc.edu> fouts@lemming. (Marty Fouts) writes: > >I offer, only half humorously, TSO running under OS/360, as the first >example of "multiple THREADS of control executing within a single >address space" Again, "threads" or multitasking is a very old technology, a natural outgrowth of the fact that I/O is too slow to be done synchronously. In more recent operating systems (well, in Unix, which seems to be what everyone means by OS) I/O scheduling is done among processes, i.e. when a process initiates an I/O operation it is suspended until that operation completes. Other systems allow various mechanisms to allow the process to continue past the I/O call, with some means of announcing when pending operations complete. A program using such a facility is multi-threaded in the simplest sense, and a more elegant model is easily constructed from such a system. The DTSS system (Dartmouth TimeSharing System, though they call it something else these days) relies heavily on this model. Far from the more common approach these days, the command processor (shell equivalent) is a single program, which holds open all user terminals with a task (thread, LWP) to handle each. The original system was based on an assembly language model, and so the notion of a task was loose and up to each application; over the years subroutine packages provided cleaner interfaces in Dartmouth's dialect of XPL and then PL/I. A few years ago the OS, PL/I compiler and runtime system were modified to provide an excellent multitasking model that's cleaner and more usable than anything I've seen since (to be fair, if you get to control the OS, the language, and the runtime system, and are unconcerned about portability, you have a lot more leeway than e.g. trying to make something that does all this in portable C). I know that IBM PL/I and Ada also provide language support for multitasking, and have been somewhat surprised not to see these mentioned. Has the CS world really forgotten everything that came before C and UNIX, or is that just a feature of the UNIX bias of usenet? -- Jim Perry perry@apollo.com Apollo Computer, Chelmsford MA
jrg@Apple.COM (John R. Galloway) (11/05/88)
Data General has had multiple tasks (threads) running around in the same address space at least since the mid 70's. I think such existed in the early versions of RDOS (just forground and background processes) as well and that would be in the early 70's. apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
raveling@vaxb.isi.edu (Paul Raveling) (11/05/88)
[ Historial interest. Unless something great comes up this will be the last ] [ on "Earliest use of Threads" --DL ] In article <5338@saturn.ucsc.edu> fouts@lemming. (Marty Fouts) writes: > >I offer, only half humorously, TSO running under OS/360, as the first >example of "multiple THREADS of control executing within a single >address space" > >Consider that TSO ran as a partition and invoked its own round robin >scheduler to schedule its quantum among its various terminal users, >all of which were (sort of) within the same address space. If TSO >doesn't qualify, IBM implementations of APL workspaces might. . . Another nomination is the "console system" that ultimately was named "URSA" at UCLA. The initial version began running around the end of 1966 on a 360/40 at UCLA CF. It also did its own scheduling for what the current jargon would call light weight processes, and was in service for UCLA users well before TSO's advent. Each "console process" had a lavish allocation of 4K of core for data storage. The first consoles (now we'd say terminals) the system supported were IBM 2260's, attached to a 2848 controller that was physically about the size of a VAX 11/780 and used acoustic delay lines for local storage. As hardware technology advanced, URSA added support for CCI terminals, whose individual controllers would make excellent boat anchors. URSA migrated through 360/75's and finally reached a model 91 in 1968. Hopefully there's a "RIP" epitaph for it somewhere, even though the rest of the late '60's IBM-world software technology seems to be carrying on pretty much as it was then. --------------------- Paul Raveling Raveling@vaxb.isi.edu