I want to know how the first programs to be able to execute more than one programs within a common time span were like . I went through the history of the topic and it seemed like Strachey was the first one to work on multi-programming . Hence , i thought of reading his paper "Time sharing in large and fast computers"

Where can I find this paper ?

Is it so that in multi- programming , two addresses are stored in a memory location and the program counter is sequentially switched between the values in the two locations and after the execution of instructions the value in the corresponding register is incremented ? So basically for a language to support multi-programming the keyword or function ,it should use to create concurrent programs or to make two programs run in parallel , should translate to a machine code having conditional jump instructions .

For example , a version of AlGol 60 , used "cobegin" and "coend" keywords to mean the parallel execution of two streams of instructions as follow :

Cobegin :

process 1 Begin :..... End

process 2 begin .......End


So , is it so that cobegin and coend translate to a machine code which stores the addresses of the machine codes obtained from translation of process1 and process 2 to two different registers , and use jump instruction to sequentially switch between the present values in the registers which are incremented as the programs get executed .

P.S : It would also be of great help , if someone can point towards a link where the code for the OS used by Burrough's written in ALGOL60 is available provided such a link exists .


2 Answers 2


The early multiprogramming systems ran two or three programs simultaneously in a single computer. They did so by partitioning the memory amongst

  • operating system
  • one user-program
  • another user-program
  • ...

The user programs shared a single copy of the operating system, which provided input/output and other services through system calls, which switched the processor into a special privileged mode that can access the external hardware. Programs had to be relocatable - able to run wherever in the memory they happened to end up.

Many advances were made in the Ferranti Atlas hardware and operating system:

  • virtual memory - both mapping and one-level store;
  • memory-addressed hardware;
  • three-level processing hierarchy: interrupt, supervisor, and user;
  • SPOOLing - buffering of slow input/output devices.

Time-sharing - time-division multiplexing of processor and sometimes of computer memory - dragged behind, and proved difficult to make a success of.

Multi-tasking within a single programming model is different and developed almost orthogonally.


Multiple program execution on a single-core CPU, whether time sharing (which I generally understand to mean multiple users each seeing the computer as their own), multitasking (multiple distinct programs running for one user) or multiprogramming (multiple threads of execution inside a single program like the cobegin/coend you mention) is generally handled by having multiple threads of execution - each with its own stack, program code area (possibly shared & reentrant, but not necessarily), data area, program counter, etc.

Essentially, under either OS (time sharing, multitasking) or program control, the CPU is switched around between multiple executing processes as needed. The switching can be time based (e.g., every 1/60 of second or more or less frequently depending on the CPU and OS), interrupt driven or cooperative (programs designed to run for a short amount of time and go to sleep/hand off to the supervisor for the next process to run).

There are some other ways of doing things - multi-core CPUs can truly execute multiple tasks as the same time, 1 per CPU but often with shared memory & I/O; and massively parallel systems may really have methods where small groups of instructions (or even individual instructions) are applied to multiple CPUs at the same time, with each operating on a different chunk of memory, but typical multitasking is in some ways not much more complex than CPU being interrupted for peripheral I/O.

In the case of the cobegin/coend example, I assume that two separate processes (again, could be OS control or program control depending on the OS capabilities) are spawned and the main program simply waits until all processes have been reported as completed.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.