Processes

Multiprogramming -- on a uniprocessor, switching the CPU among runnable processes in memory every 100ms or so, also called pseudoparallelism. OS does this context switch after every so many hardware clock interrupts.

True parallelism on a uniprocessor: IO device DMA while CPU is executing some other program (IO device ``steals'' cycles) (also multiple functional units, vector processing unit)

Process states

  ready <--> running         running process can issue IO request and block
    ^             |          running process can use up its time quantum
    |             |          ready process can get scheduled on CPU
    |             |          blocked process can have its request done
    --- blocked <--

Threads

• Each process has its own address space
• a process may have multiple threads running in it.
  • each thread shares the process address space with all other threads in the process
  • each thread has its own program counter (PC), register values, stack
  • concurrent programming (using SR)

Concurrent programming has its roots in operating systems.

In the 1960's, independent device controllers were added to computers, each programmable itself.

So the OS came to be organized as a collection of concurrently executing processes.

For example,

• tape-to-tape copy needs synchronization to avoid overwriting buffers that are full, to avoid reading buffers that are empty
• card reader to disk buffer, then EBCIDIC to ASCII (disk to disk), then print on line printer (disk to printer)
• OS is handling an interrupt then a higher priority interrupt comes in and gets handled; if both manipulate the same queue, then corruption is possible
• OS may be arranged as several independently executing tasks or ``daemons'' that share data or execute in the same address space

The tools built into the OS to control process synchronization have become available to users for concurrent/parallel programming.

• shared memory: semaphores, threads, barriers, monitors
• distributed memory: message passing

The article An Introduction to Programming with Threads by Andrew D. Birrell (1989) motivates concurrent programming with threads:

• shared memory multiprocessors are cheaper and more common so each thread can be allocated a CPU;
• it is less expensive and more efficient to create several threads in one process that share data than to create several processes that share data;
• IO on slow devices like networks, terminals, and disks can be done in one thread while another thread does useful computation in parallel;
• multiple threads can handle the events (e.g., mouse clicks) in multiple windows in the windowing system on a worksation;
• in a LAN cluster of workstations or in a distributed operating system environment, a server running on one machine can spawn a thread to handle an incoming request in parallel with the main thread continuing to accept additional incoming requests.